実例によるkotlinx.coroutinesガイド（日本語訳） - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
ロックフリーアルゴリズムによるFIFOバッファ - Qiita
はじめに 私が組み込みプログラミングを始めたころ(まだインターネットもなく組み込みマイコンもAKI-80とかZ80系主流で遊んでいた時代)に大学の先輩に教えてもらったテクニックです。今どきのCPU向けではないですが、私自身が古典的かつ重要な要素が含まれており、組み込みプログラミングに引き込まれたきっかけの一つでもありますので、当時を思い出しつつ記事にしてみます。 「ロックフリーなアルゴリズム」についてはこちらのWikipediaの記事がわかりやすいです。 これらのアルゴリズムは、割り込み禁止やミューテックスなどのロックを用いずに、割り込みハンドラやマルチタスク／マルチスレッドなどの異なる非同期な実行コンテキスト間で情報を渡すことを目的としており、今回はその応用内でのFIFOバッファの構成例となります。 近年ではArduinoなどの組み込みプログラミングも手軽に行える環境が増えています。また
ロックフリーアルゴリズムについて理解する - 逐次一貫性 - 高速日記
逐次一貫性(sequential consitency)とは何か 最初に逐次一貫性の概念についてまず理解しよう 逐次一貫性はコンピュータシステムに関するメモリ一貫性モデルの一つであり、定義をWikipediaから引用すると「どのような実行結果も、すべてのプロセッサがある順序で逐次的に実行した結果と等しく、かつ、個々のプロセッサの処理順序がプログラムで指定された通りであること」とのことだ。 何のことだかよくわからんが、並列処理中の実行結果が常に逐次的に実行した場合と同等となる、ということのようだ。 例えば下記のようなコードがあるとして std::atomic<int> X(0), Y(0); int r1, r2; void thread1() { X.store(1); r1 = Y.load(); } void thread2() { Y.store(1); r2 = X.load();
Lock-freeとWait-freeアルゴリズム - Wikipedia
Lock-freeとWait-freeアルゴリズムとは、共有データにロックをかけてアクセスを防ぐアルゴリズムとは違い、複数のスレッドが同時並行的に、ある対象データを壊すことなしに読み書きすることを可能にするアルゴリズムである。Lock-free とはスレッドがロックしないことを意味しており、全てのステップにおいてシステムが必ず進行する。これはLock-free ではミューテックスやセマフォといった、排他制御のためのプリミティブを使ってはならないことを意味する。なぜならロックを持っているスレッドの実行が中断した場合、全体の進行を阻止しうるからである。Wait-free とは、他のスレッドの動作に関係なく、スレッドがいかなる操作も有限のステップで操作を完了させられることを指す。あるアルゴリズムがLock-freeであるがWait-freeでないことはありうる。Wait-free なアルゴリズム
分散プログラミングモデルおよびデザインパターンの考察 その3 - Software Transactional Memo
昨日に引き続いて分散システムのデザインパターンについて書いていきたい。 だがそれ以前に故障モデルに関する前提を忘れてはならない。人によって様々な方針があるが、個人的には分散システムの世界において意識しなくてはならない故障モデルは4つだと考えている。僕は前回のブログに書いた Replication の本をベースに書いており、少し言葉遣いや定義が他とやや違う点は許して欲しい。また、通信の脱落・遅延とはレイヤーが異なる議論である。 故障モデルの分類 故障が起きないモデル これは故障が起きない世界を仮定するモデルである。これ自体はプロダクションにそのまま投入できるものではない。だがこの故障モデルを想定しても解けない問題は故障が発生する状況では絶対解けない事が断言できたり、合意プロトコルが正しいかを議論する土台となったり、様々な実用的なアルゴリズムや分散システムの土台となるアルゴリズムが生まれる土壌
分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの本質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか？」「データフローは
分散プログラミングモデルおよびデザインパターンの考察 その1 - Software Transactional Memo
Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の３つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ
分散プログラミングモデルおよびデザインパターンの考察
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 写真：アフロ データ＆サイエンスソリューション統括本部、データインフラ本部、今野です。 早速ですが、今月開催の「Developers Summit 2016 （以下、デブサミ2016）」で当方が登壇する運びとなりました。気がつけば、前回の記事「分散システム処理モデルに関する動向について」から随分と日がたってしまいましたので、今回は、より広範囲な内容を整理してみたいと思います。 デブサミ2016の当方の講演テーマは「温故知新」です。今回は、このテーマにもつながる話題として、クラウド環境の代表的な分散プログラミングモデルやデザインパターンについて、一般的な考察をしてみたいと思います。 古典的なプログラミングモデルによる分類 まず最初に
C++11のスレッド、アフィニティ、ハイパースレッディング | POSTD
背景と導入 何十年もの間、CやC++の標準規格は、マルチスレッディングや並行処理を「その標準の範囲を超えたもの」として扱ってきました。標準規格の目的である”抽象機械”の力が及ばない、”対象依存”という影の世界においてです。メーリングリストやニュースグループの質問には並行処理に関するものが山ほど寄せられましたが、それらにすぐに突き返された回答は「C++はスレッドには関知しません」という何とも冷淡なものでした。この件によって当時のことを思い出す人々は、今後も絶えないでしょう。 しかしC++11の登場で、そんな状況に終止符が打たれたのです。C++標準化委員会は、時代の流れに乗らないと、この先C言語が取り残されてしまうと悟ったのでしょう。彼らはスレッドや同期メカニズム、アトミック操作、メモリモデルなどの存在に、ようやく気付いたわけです。そして標準規格として、C++コンパイラやライブラリのベンダーに
C++11で始めるマルチスレッドプログラミングその1 ～std::thread事始め～ - すいバカ日誌
この記事は、C++11におけるマルチスレッドプログラミング入門記事という位置づけで書かれたものです。簡単のため、表現が曖昧になったりしている部分があると思いますが、もっと厳密に知りたいという方はC++の規格を参照してください。 C++11のマルチスレッドライブラリ C++03までは、マルチスレッドプログラミングを行うための言語機能やライブラリが標準で用意されていませんでした。そのため、プログラマはしばしばプラットフォームに依存したコードを書く必要がありました。 しかしC++11から、thread-aware memory modelなどの定義や、マルチスレッドをサポートするための言語機能とライブラリが導入されました。これによって、プログラマは抽象度の高いコードを用いてマルチスレッドプログラミングを行うことが容易になりました。 本記事では、事始めとしてstd::threadを用いて簡単なプロ
C++11における同期処理(std::mutex, std::unique_guard, std::lock_guard, std::condition_variable) - Qiita
前回は非同期処理についてまとめたが、 今回は並行(concurrent)処理中の同期が必要な処理をC++11で実行するために必要な知識をまとめていく。 ThreadPoolを実装するために必要な知識として、 mutexによるロック 条件変数の使い方 をまとめる。 ThreadPoolはまた次回に持ち越しである。 mutexを用いたロック: std::unique_lock or std::lock_guard ? スレッド間でもプロセス間でも相互排他処理、 つまりある操作を同時に実行するスレッド/プロセスが一つである事を保証する必要がある場合がある。 このような排他的に実行する必要のある処理をクリティカルセッションと呼ぶ。 相互排他処理を実現するための同期機構としてmutexというものがある。 Wikipediaによれば相互排他(MUTual EXclusion)の省略形が語源だそうだ。
introdunction to SIMD programming - primitive: blog
Unite 2015 Tokyo の講演で詳細を話せなかったのが心残りだったので、大量のオブジェクトの更新処理についてこの場で書いてみます。 主に C++ で、簡単なパーティクルエンジンを作り、それを SIMD を用いて高速化する手順を解説します。 話を簡単にするため、以下の前提を設けます。 ・x86 環境のみ考慮 ・パーティクルは位置と速度のみを保持 ・パーティクル同士の相互衝突は総当たりで計算 総当たりなので超遅いですが、実装は容易で SIMD による恩恵を受けやすく、題材として手頃です。 この記事の中で引用されているソースの元は こちら、ビルド結果 (上のスクリーンショットのデモプログラム) は こちら になります。 相互衝突するパーティクルを実装する場合、お互いの距離を計算し、当たっていたらめり込み具合に応じて押し返す、というのがよくある実装だと思います。まずはそれをストレートに
C++ マルチスレッド 入門
Pythonの処理系はどのように実装され，どのように動いているのか？ 我々はその実態を調査すべくアマゾンへと飛んだ．
非同期処理の基礎
ThreadよりもTask for (int i= 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[i] = F(a[i]) ); } ×悪い例 ○良い(まだマシ※な)例 データの数だけ スレッド作成 Threadでなく Task利用 ※ この場合、ParallelクラスやParallel.Enumerableクラスが使いやすい ThreadよりもTask for (int i= 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[i] = F(a
スレッド・並行プログラミング/ マルチコア・並列プログラミングを学びはじめるためのN冊 - laiso
読みたい本のリストを作ってる(いくつかは購入済み)。 なんかおすすめあったら教えてください。 でもこういうのってリスト作って仕事した気になって満足してしまう。 並列と並行 学びはじめる前なんだから当然よくわかってはいないんでけど、並列と並行処理の違いは以下で認識してる parallel と concurrent、並列と並行の違い - 本当は怖い情報科学 parallel と concurrent 、並列と並行の覚え方 - まめめも (追記) 孫引きなんだけど「コーディングを支える技術 171P」に「プログラミング言語の概念と構造」から引用した記述があった ここでは並行→プログラミング上の概念、並列→ハードウェアレイヤーの話となっていますね。 並列処理・並行処理がプログラミングに必要な理由 マルチコアを生かしたパフォーマンスの向上 大規模なデータの処理 GUIアプリケーションのユーザビリティ
非同期処理をちょっとはラクに。Promises:aほか
JavaScriptで ごく普通にhttp通信をする 〜esp8266+espruinoでhttp getリクエストをするテスト〜
マルチコア時代に備えて本気でメモリモデルを理解しておこう - リオーダー & finalフィールド 編 - - かとじゅんの技術日誌
長い文章になってしまったので、概要だけ先に書きます。 以下のJavaプログラムは、常に上から下に順番に命令が実行されると思いますか？つまり、aに1が格納された後に、bに2が格納されると思いますか？ 実は場合によってはこの実行順序が入れ替わる場合があります。これはJavaの言語仕様として定義されていることです。これを考慮しないと信頼性のある並行処理は実装できません。 気になる人は以下を読んでみてください。 a = 1; b = 2; すでにインターネットは社会インフラ化しています。ソーシャルネットワークで多くの人とコミュケーションやコラボレーションできる時代で、個人が情報を作り消費することは当たり前になってきています。そして、インターネット上のコンテンツは増加の一途を辿っています。「情報爆発」なんて言葉も耳慣れた言葉になりましたが、その問題解決のためにMapReduceなどの分散処理技術に注
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Introduction to Kotlin Coroutines | Baeldung on Kotlin
並列化による高速化
http://japan.internet.com/m/developer/20081209/26.html