タグ

threadに関するy-kobayashiのブックマーク (14)

  • NSLockメモ - Qiita

    詳しくは「スレッドプログラミングガイド」参照 ロックはスレッドの排他制御に必要。 注:アップルはスレッドプログラミングではなくより簡便な代替テクノロジー(NSOperation, GCD, アイドル時間通知、非同期関数、タイマー、別プロセス)を使うことを勧めている。 スレッドの実装 スレッドの基礎にある実装メカニズムはMachスレッド POSIX API スレッドの3つの状態 実行、実行可能、ブロック NSLockingプロトコル ロックオブジェクトが持つべきメソッド。lock,unlock。 lock ロックを取得する。ロックが取得できるまでスレッドを止める。 unlock ロックを開放する。 NSLockingの実装の一つ。 NSLockingプロコトル以外により細かな制御ができる。 tryLock: ロックでなかったときに直ちにNOを返す。lockが開放されるまで待つのと対照的。 l

    NSLockメモ - Qiita
  • NSRecursiveLock による排他制御を行う : Objective-C プログラミング

    Objective-C には、複数スレッドからの同時アクセスをブロックする機能を持った NSRecursiveLock が利用できます。 この NSLock というクラスは、内部的には POSIX threads の ミューテックス を使った排他制御と同じだそうです。ミューテックスというのは、それで制御されている区間が「使用中か」「未使用か」を判断するための機構です。 類似するロックに NSLock がありますけど、今回扱う NSRecursiveLock では、同一スレッドからの再ロックであれば通過させる「再帰的ロック」という方式を採用しています。 POSIX threads のミューテックスのロックの種類で言えば、この NSRecursiveLock では PTHREAD_MUTEX_RECURSIVE に該当するようです。 ここでは NSRecursiveLock をつかって、複数ス

  • swiftで使えるAtomic系API (OSX/iOS) - Pebble Coding

    swiftで使えるAtomic系APIがあったので備忘録としてリストアップしておく。 OSX/iOSで確認した。 func OSAtomicAdd32(__theAmount: Int32, __theValue: UnsafeMutablePointer<Int32>) -> Int32 func OSAtomicAdd32Barrier(__theAmount: Int32, __theValue: UnsafeMutablePointer<Int32>) -> Int32 func OSAtomicIncrement32(__theValue: UnsafeMutablePointer<Int32>) -> Int32 func OSAtomicIncrement32Barrier(__theValue: UnsafeMutablePointer<Int32>) -> Int32 f

    swiftで使えるAtomic系API (OSX/iOS) - Pebble Coding
  • スレッド処理は慎重に – PHPでのスレッド処理 : 前編 | POSTD

    私が覚えている限り、非常に重い(または非同期の)タスク処理に関して、PHPは常に厳しい評価をされていました。これまではずっと、長いタスクを並列化したければ pcntl_fork を通してフォークするという方法を取らなければいけなかったので、タスクの結果を適切に処理することができませんでした。 そこで私たちは、キューイング(どちらかと言えばタスクを遅くするだけ)やReactPHP、または他の言語を一緒に使うといった、より複雑なソリューションへと向かっていきましたが、PHPでもスレッド処理は可能なのです。そしてより重要なのは、 その方法はあなたが思っているよりもはるかに簡単だということです。 この記事では、 pthreads 拡張(POSIX Threadsの略)について説明します。2012年ごろから広く使われていますが、多くの人がその存在を忘れているか、使うのが苦痛だと考えると思います。その

    スレッド処理は慎重に – PHPでのスレッド処理 : 前編 | POSTD
  • Realm Objective-C & Swift 2.2: スレッド間のオブジェクトを受け渡し、関連による並べ替えなどをサポート

    Realm Objective-C & Swift 2.2: スレッド間のオブジェクトを受け渡し、関連による並べ替えなどをサポート これまでのRealmの設計が目指していたもののひとつに、一貫性があり、わかりやすいスレッドモデルを提供するということがありました。このたび、 Realm Objective‑C および Realm Swift 2.2より、安全にスレッド間をまたいでオブジェクトを受け渡すことができる仕組みを用意しました。また関連のプロパティを並べ替えに使用することがこのバージョンからできるようになりました。その他、同期に関する改善と不具合の修正が含まれます。 スレッドに従う 日より、Realmでは複数のスレッド間でオブジェクトを扱うことがさらに簡単になりました。これまでのマルチスレッドの対応は何年もの間の絶え間ない議論の果てに下された決断で、意図的なものです(なぜなら、 マル

  • Swift 世代の排他制御 - Qiita

    Update: 関連する記事のリンクを追加しました。 Swift 3 世代の排他制御 http://qiita.com/codelynx/items/56ce2f91cd3f4f409aeb 今回は Swift で排他制御が必要になった時の TIPS を紹介したいと思います。 Objective-C時代の古き良き排他制御 GCDを使った排他制御 NSLock と defer を使った排他制御 Objective-C時代の古き良き排他制御 Objective-C の時代に排他制御のコードを書いた人は @synchronized をよく使ったと思います。簡単な構文で手軽に排他制御できていたので重宝していたかと思います。 // Objective-C 時代の排他制御 - (NSData *)readDataRange:(NSRange)range { @synchronized(self) {

    Swift 世代の排他制御 - Qiita
  • スレッドプールのサイズを調整する

    この他にも "サービスを受けるのを待つ人が,キューの中に立っている平均時間はどれくらいか?" といったような疑問に,Littleの法則で答をだすといった内容のゲームは,他にもたくさんあります。 図1. Littleの法則 同じようにLittleの法則は,スレッドプールサイズの決定にも使うことができます。私たちがしなければならないのは,リクエストの到着率と,サービスに必要な平均時間を測定することです。そうすれば,これらの値をLittleの法則に挿入して,システムの平均要求数が計算されます。その数値がスレッドプールのサイズよりも小さければ,その結果に従ってプールのサイズを小さくすることが可能なのです。逆に計算結果がスレッドプールのサイズよりも大きい時には,問題はもう少し複雑になります。 実行中のリクエストより待ち状態のリクエストの数が多い場合,まず最初に判断しなければならないのは,もっと大きな

    スレッドプールのサイズを調整する
  • InfoQ: RubyのFiberを非同期I/Oに使うNeverBlockとRevactor

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    InfoQ: RubyのFiberを非同期I/Oに使うNeverBlockとRevactor
  • MySQLPlus と NeverBlock

    前に Rails がマルチスレッドになっても MySQL のドライバとかがブロックしたらダメじゃないの? という話をちらっと書いた. やっぱりダメというのが結論らしい. MySQLplus は そんな問題に対処する rubyMySQL ドライバ拡張だというので眺めてみた. MySQLAPI がブロッキングで困るだなんて, まったく他人事には思えない. MySQL ドライバの API は基的にマルチスレッド+ブロッキングを前提とした設計をしており, 刺さりそうな場所は多い. 中でも一番困りそうなのは mysql_query() や mysql_real_query() だろう. ばしっとクエリーを投げて結果を受けとるこれらの API は, MySQL から返事が戻ってくるまでデータを待ち続ける. MySQL/Ruby もこの API を使っている. 普通に考えるとお手上げに見え

  • Play Framework: async I/O without the thread pool and callback hell

    Play Framework: async I/O without the thread pool and callback hell Under the hood, LinkedIn consists of hundreds of services that can be evolved and scaled independently. That is, all functionality is broken down into separate codebases, deployed on separate hardware, and exposed via well-defined APIs. For example, we may have separate front-end services (e.g. Profile, Skills) that talk to separa

    Play Framework: async I/O without the thread pool and callback hell
  • オワコンであるVectorとListの同期の話 - プログラマーの脳みそ

    JJUG Night Seminarへ行ってきました - 虎塚にあったjava.util.Vectorの話。 java.util.Vectorは随分前にオワコン化していて、今、新たにVectorを使ってコードを書く人がいたら優しく諌めてあげるべきシロモノ。 「VectorとArrayListだとArrayListの方が同期化されていなくて速いです!」と習った人も多いのではないかと。 public synchronized E get(int index) { if (index >= elementCount) throw new ArrayIndexOutOfBoundsException(index); return elementData(index); } これはJDK7u7のVectorのコードのうちget()の部分の抜粋なのだけど、synchronizedメソッドになってる。s

    オワコンであるVectorとListの同期の話 - プログラマーの脳みそ
  • Which Java thread consumes my CPU?

    What do you do when your Java application consumes 100% of the CPU? Turns out you can easily find the problematic thread(s) using built-in UNIX and JDK tools. No profilers or agents required. For the purpose of testing we'll use this simple program: [code language="java"] public class Main { public static void main(String[] args) { new Thread(new Idle(), &quot;Idle&quot;).start(); new Thread(new B

  • Which Java thread consumes my CPU?

  • Threadの割り込みを活用する - プログラマーの脳みそ

    確実に一定時間スリープする - terazzoの日記ではThreadの割り込みがあっても確実に一定時間の停止を試みているが、そもそもこのようなコードは書いてはいけない。 Thread.sleep()は一定時間止まるための便利メソッドとしてよく知られているが、そのときに発生するInterruptedExceptionについての理解は広まっていない気がする。割り込みとはなんなのか。どういう時に使うのか。 目覚まし時計 お昼休みに昼寝をしようとする。寝過ごすといけないので15分後にアラームを鳴らす設定をした。 さて、ひと眠りするか、というところに友人がやってきた。昼寝はやめて売店に行くことにした。果たして売店でアラームが鳴り始めた。 さて、このとき、アラームは15分間の待機を命じられたわけだけども、お昼寝がキャンセルされたことで、もう待機しなくてよくなってしまった。むしろ、さっさと待機をやめてく

    Threadの割り込みを活用する - プログラマーの脳みそ
  • 1