パスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。
![ログイン - はてな](https://cdn-ak-scissors.b.st-hatena.com/image/square/63d047fc9c383fd41a722bede82e1da02c43f2c2/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fi%2Finfablic%2F20170315%2F20170315130020.png)
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Fault tolerance" – news · newspapers · books · scholar · JSTOR (January 2008) (Learn how and when to remove this message) Fault tolerance is the ability of a system to maintain proper operation despite f
Proof of work (PoW) is a form of cryptographic proof in which one party (the prover) proves to others (the verifiers) that a certain amount of a specific computational effort has been expended.[1] Verifiers can subsequently confirm this expenditure with minimal effort on their part. The concept was invented by Moni Naor and Cynthia Dwork in 1993 as a way to deter denial-of-service attacks and othe
ビザンチン将軍問題(ビザンチンしょうぐんもんだい、英語: Byzantine Generals Problem)とは、相互に通信しあう何らかのオブジェクト群において、通信および個々のオブジェクトが故障または故意によって偽の情報を伝達する可能性がある場合に、全体として正しい合意を形成できるかを問う問題である[1]。フォールトトレラントシステムでの多数決の妥当性や分散コンピューティングの処理の妥当性に関わる問題と言え、二人の将軍問題を一般化したものと言える。 ビザンチン将軍問題に帰結される故障や障害をビザンチン故障(Byzantine Failure、あるいはビザンチン障害)と呼ぶ。また、ビザンチン将軍問題が発生しても全体として正しく動作するシステムをビザンチン・フォールトトレラント性(Byzantine Fault Tolerance)があるという。 ビザンチン将軍問題は、東ローマ帝国(ビザ
The programming model in P is based on concurrently executing state machines communicating via events, with each event accompanied by a typed payload value. A memory management system based on linear typing and unique pointers provides safe memory management and data-race-free concurrent execution. In this respect, P is similar to modern systems programming languages such as Rust (opens in new tab
がーっと読んだ。実際に使うときの思い出しトリガーになるようにメモしておく。 Java言語で学ぶデザインパターン入門 マルチスレッド編 マルチスレッドプログラムの評価基準 安全性 オブジェクトを壊さないこと スレッドセーフなクラス 生存性 必要な処理が行われること 安全性を重視しただけでは生存性を下げてしまう場合がある。例えばデッドロック。 再利用性 クラスを再利用できること スレッドの排他制御の仕組みや方針をうまくクラスの中に隠蔽すれば、再利用性の高いプログラムになる。 パフォーマンス 処理を高速・大量に行えること 安全性と生存性を守るのは必須。その上で、いかにして再利用性とパフォーマンスを上げるかが重要。 Single Thread Execution 「この橋を渡れるのは、たった一人」 複数のスレッドがインスタンスを共有する場合の基本パターン クリティカルセッション(インスタンスが不安
スレッドとは、プログラムを実行している主体(例えて言うなら1人の人間)です。 そのマルチスレッドプログラミングについて解説していきます。 マルチスレッドプログラミング INDEX スレッド 1.1. スレッドとは 1.2. マルチスレッド 1.3. スレッドのライフサイクル 1.4. 複数のスレッドの関係 スレッドの実行 2.1. Threadクラスを継承する方法 2.2. Runnableインタフェースを実装する方法 2.3. 2つのスレッド作成方法の比較 スレッドの排他制御 3.1. synchronizedブロック 3.2. synchronizedブロックの仕組み 3.3. synchronized メソッド 3.4. static synchronized メソッド 3.5. volatile 変数 スレッドの制御 4.1. 優先度の設定 4.2. スレッドの休止・中断 4.3.
本書は、マルチスレッドと並行処理を学ぶ入門書です。 本書では、Javaのスレッドの基本から書き起こし、 マルチスレッドプログラミングによく登場するパターンを解説します。 本書を通して、マルチスレッドと並行処理に関する理解を深め、 よく使われる技法を身につけましょう。 Amazon 目次 想定読者 本書の目次 サンプルプログラムのダウンロード 誤りと訂正 フィードバック 想定読者 本書は、こんな方へおすすめです。 Javaのマルチスレッドプログラミングに興味を持っている人 Javaのスレッドについて、きちんと学びたい synchronizedって、どういうときに、なぜ書くのか、ちゃんと理解したい マルチスレッドプログラミングで何が問題になるのか、なぜ難しいかを把握したい スレッドの間で情報をやりとりする方法について学びたい スレッドを使ってパフォーマンスアップする方法について学びたい Swi
In the second part of our series we will take a look at more advanced concurrency models such as Actors, Communicating Sequential Processes, Software Transactional Memory and of course Guilds — a new concurrency model which may be implemented in Ruby 3. If you haven’t read our first post in the series, I’d definitely recommend reading it first. There I described Processes, Threads, GIL, EventMachi
Masatoshi Seki is a Ruby committer and the author of several Ruby standard libraries including dRuby, ERB, and Rinda. He’s an expert in object-oriented programming, distributed systems, and eXtreme programming. He has been speaking at RubyKaigi every year since 2006 when the Kaigi first started. Ruby threads are amazing, but for some reason they don't seem to be very popular. So I decided I'd try
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
Victor Savkin is a co-founder of nrwl.io. He was previously on the Angular core team at Google, and built the dependency injection, change detection, forms, and router modules Building a web application involves coordinating multiple backends, web workers, and UI components, all of which update the application’s state concurrently. This makes it easy to introduce bugs due to race conditions. In th
At Teachers Pay Teachers, we take performance seriously since it is widely accepted that performance delights users, increases Search Engine rankings and improves conversion rate. In this post, we’ll talk about how we reduced our product page upper 90th percentile response time from 120ms to 20ms. To begin, you should take a look at an example product page and note the types of information display
Stanislav Vishnevskiy (Discord CTO) recently shared in a blog post the details of Discord's elegant use of Elixir to handle its intense messaging needs. His article was of particular interest to me and to the Nanobox team for a couple reasons. Our distributed team uses Discord as a critical part of our team communication infrastructure. Also, our founder, Tyler Flint, and members our development t
Welcome to the last Ruby Magic article in our series about concurrency. In the previous editions we implemented a chat server using multiple processes and multiple threads. This time we're going to do the same thing using an event loop. Recap We're going to use the same client and the same server setup we used in the earlier articles. Our aim is to build a chat system that looks like this: Please
並列処理の複雑さ 例えば以下の様なスクリプトを組むとします。 WebサーバーAにアクセスするとレスポンスとして4つのURLが得られる。それらは下記の売り上げ数量サーバー4台(B,C,D,F)のURL。 売り上げ数量サーバー(B,C,D,F)のレスポンスはそれぞれが対応する4店の売り上げ数量。 WebサーバーGのレスポンスは商品単価。 スクリプトでは売り上げ数量サーバーから商品売り上げ数量を取得し、WebサーバーGの商品単価を掛け合わせた合計を表示する。 単純にbashとcurlでスクリプトを書くと以下の様になるでしょう。 curl http://[WebサーバーA] > URLs #1 売り上げB=`curl $(sed -n '1p' URLs)` #2 売り上げC=`curl $(sed -n '2p' URLs)` #3 売り上げD=`curl $(sed -n '3p' URLs)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く