How to Choose the Right Python Concurrency API Python standard library offers 3 concurrency APIs. How do you know which API to use in your project? In this tutorial, you will discover a helpful step-by-step procedure and helpful questions to guide you to the most appropriate concurrency API. After reading this guide, you will also know how to choose the right Python concurrency API for current and
スレッドローカルは便利なクラスです。 いつでもどこでもスレッドセーフなグローバル変数を定義することができます。 ごく稀にですが、スレッドローカルを使わないと解決できない問題もあるでしょう。 しかし、思うのです。スレッドローカルを使うのは基本的に「負け」なのだと。 例えば 例えば、こんなコードがあったとします。 public class FooAction implements WebAction { // 入力フォームのバリデーションを行う。 @Override public void validate(Form form) throws ValidationException { if (form.get("name") == null) { throw new ValidationException("name is null"); } if (form.getInt("age") <
デバッグ中の発見 とあるマルチスレッドプログラムをPythonで書いていた際に遭遇した誤使用です。C/C++等の言語を使った場合には起こらない仕様なので、知っておくと役立つ時がくるはずです。これはPythonだけでなく、Rubyでも同様のことが起こるので、Rubyistさんも是非気をつけていただければと思います。 @ahaha_traderさんのご指摘により、C/C++でも同様のことが発生することを教えていただきました・・・。不勉強をお詫び申し上げます。 このブログを見ているような方々だとバグが生じる実際のコードと、結果をまずお見せしたほうが良いと思うので、サンプル用に作ったコードがこちらです。 バグが生じるソースコード import Queue import threading class MultiThreadIncrement(object): def __init__(self,
こんにちは。開発企画室の佐島です。 はじめに 5月14日（水）、グリー主催の技術勉強会GREE Tech Talkが開催されました。 5回目となる今回のテーマは「並行/並列プログラミング」。 少々マニアックなテーマで集客に不安があったものの、結果的に200名近い技術者の方々にご来場頂くことができました。 お忙しい中お越し頂いたみなさま、本当にありがとうございました。 セッション概要 当日行われたセッションについて簡単にご紹介させていただきます 冒頭、弊社CTOのふじもとがご来場頂いたみなさまに並行、並列、分散プログラミングがテーマになっている「プログラミングの魔導書 Vol.3」を持っているかどうか聞いたところ、半数ぐらいの方がお持ちでした。 残り半数の人達に売れるチャンス！というのは今回の目的ではありませんが、来場者の関心の高さが伺えたところでセッションがスタートしました。 『ここから始
closureで継続(continuation)を実現する技法ってあるじゃないですか。 例えば次の記事は私が5年以上前に書いてますね。 C#2.0時代のゲームプログラミング(49) 〜 delegateを用いたcontinuation http://d.hatena.ne.jp/yaneurao/20070207 上の技法は私は10年ぐらい前にclosureを使い出したころに自力で発見しましたが、まあ、いまや常識ですよね。それで最近、それに似た話題があったので取り上げてみます。 ここで再度認識して欲しいのは、node.js の素晴らしさは「クライアント側で皆が使っているJavaScriptでプログラムが書ける」という部分などにあるのではない、という点だ。node.js がこれほど多くの支持者を得ているのは「本来記述が煩雑になりやすい非同期処理をJavaScriptの無名関数を利用して書きや
ここ数日、 node.js で色々と作りはじめているのだが（node.js が一番力を発揮するのは、xmpp server や、push notification server のようにソケットを開きっぱなしにして非同期通信をするケースだと思うのだが、それについては来週のメルマガで詳しく解説する）、これで思い出すのが Microsoft 時代の「"thread hog" 退治」だ。 "thread hog" とは私が作った造語で、"memory hog" （メモリをやたらと使うプログラムのこと）と同じように、thread を不必要に作るプログラムのこと。 最初に出会った thread hog は、Microsoft が作っていた proxy server だった。コネクションが１０００を超すとやたらと遅くなり、しまいには落ちてしまうという欠点を持っていたため、一時は「出荷出来ないところか、
STMはソフトウェアトランザクショナルメモリの略です。 ↓とりあえずwikipedia http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%AB%E3%83%A1%E3%83%A2%E3%83%AA 日本でSTMの話題を検索すると「楽観的ロックでしょ？」といった発言を見かける事が多く、確かに実用的な手法の多くはロックベースだったりしていますが、正直なところロックベースな手法のSTMはデータベースでのトランザクションと似ているフシがあったりしてデータベースに詳しい人からするとそれほど驚くような手法ではない事が多いのです。その
AndroidでWeb APIを使う場合、マルチスレッドによるユーザビリティ向上を以前のエントリで説明しました。 AndroidアプリのUIはシングル・スレッド モデルです。 単純にマルチスレッドにしてUIの操作をしてしまうと、CalledFromWrongThreadExceptionでアプリがダウンしてしまいます。 これを回避する仕組みがHandlerです。 Handlerの仕組みを簡単に説明しようと思ったのですが、 またもや長くなってしまったので、先にまとめます。 AndroidのUI操作はシングル・スレッド モデル ユーザビリティ向上の為にはマルチスレッドが必要 Handlerで実現 Handlerを使わない場合に起きる例外は実行スレッドのチェックで発生 Handlerを使うと、UI Threadの持つキューにジョブを登録できる キューはUI Threadにより実行される
[This post is by Gilles Debunne, an engineer in the Android group who loves to get multitasked. — Tim Bray] A good practice in creating responsive applications is to make sure your main UI thread does the minimum amount of work. Any potentially long task that may hang your application should be handled in a different thread. Typical examples of such tasks are network operations, which involve unpr
第53回 社内勉強会に使用したテキストファイル「はじめての並行プログラミング(1)」 今回話すことスレッド？ 並行プログラミングの難しさ 複数の仕事を同時に『並行プログラミング』とあるプログラムで何かの処理を同時におこないたい 方法は大きく分けて二つプロセススレッド（軽量プロセス）※ スレッド in プロセス の関係。プロセスとスレッドの違い（簡単に言えば）プロセスは「資源を共有しない」。スレッドは「資源を共有する」。スレッドが共有するもの メモリアドレス空間、ファイルハンドルなどスレッドが共有しないもの プログラムカウンタ、スタック、ローカル変数スレッドを使うメリットよいとこ 一つのプロセス内で並行処理が可能 非同期な処理とか 起動も低コスト データの同期が低コスト グローバル変数で受け渡しなどわるいところ 共有データの扱いが難しい（超重要）スレッドの安全性（safety）スレッドセーフ
前エントリWeb2.0とC10Kに関する数々の誤解に関してはいろいろツッコミをいただいた(ありがとうございます). 名無し 『誤読した上にえらそうに微妙な解説するあたり恥ずかしすぎます。』 えらそうで微妙な解説なのはまぁそうなので否定しないが,誤読とはなんのことだろう? こういうときは今はやりの「スルー力」を発揮するのが大人のインターネットかと思ったけれど, 私のBlogが扱う内容は非常に狭く,さらにそれに対して突っ込もうと思う人の 意見はなにかしらの真実が含まれるはずと考えていたところ,下記エントリがあった. 元記事の人は上でいう 3，6 あたりを書いていて，id:yamaz さんは 3 するなら 4 とか常識だろ，と噛みついているように読めました。. なるほど,私の前エントリは@ITの元記事に対して噛みついているように 読めるようだ(言われてみればたしかにそう読める). 実際の所は元記
The "Double-Checked Locking is Broken" Declaration Signed by: David Bacon (IBM Research) Joshua Bloch (Javasoft), Jeff Bogda, Cliff Click (Hotspot JVM project), Paul Haahr, Doug Lea, Tom May, Jan-Willem Maessen, Jeremy Manson, John D. Mitchell (jGuru) Kelvin Nilsen, Bill Pugh, Emin Gun Sirer Double-Checked Locking is widely cited and used as an efficient method for implementing lazy initialization
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
