Modeling users |> Preparation |> User data model |> User |> Verify |> Add password colum |> Encrypted password |> Additional verification |> Before the end
[Rails Tutorial for Phoenix]Modeling users
Modeling users |> Preparation |> User data model |> User |> Verify |> Add password colum |> Encrypted password |> Additional verification |> Before the end
CREATE INDEX CONCURRENTLY を読み解く - Qiita
Explaining CREATE INDEX CONCURRENTLY というブログ記事がなかなかおもしろかったので、自分なりにまとめなおしてみます。PostgreSQLのソースコードでもコメントで説明されているので、それを読むのもおすすめです。それ読みながら書きました。 通常インデックスの作成時には、その最中にインデックスに影響する変更が行われるのを防ぐため、テーブルレベルのロックが行われます。CREATE INDEX CONCURRENTLY はこのようなロックを行わずにインデックスを作成する機能です。 （ソースコードやネット上の記事を参考に書いているので、勘違い等あればご指摘ください） どうしたら実現できるか 基本的な考え方は、ある時点のスナップショットを元にインデックスを作成し、インデックスへの挿入を有効化してから、改めて取ったスナップショットとの差分をインデックスに反映するとい
60min.第13回「Background Job Worker座談会」 | けんちゃんくんさんのWeb日記
ursmから、このようなものが何故必要なのか、そしてidobataで実際にどう利用しているのか、ということを話してもらった。 なぜ必要なのか Railsのプロセスはだいたい200Mくらいはメモリを使うので、たとえばそれを32個上げるとするとそれだけで 200M * 32 でだいたい6Gくらいのメモリを使うことになる。(そして、メモリは普通有限なのだ) たとえば1秒かかる処理があると、同時に捌けるリクエストは32個になってしまい、33個目は1秒後に処理が開始されることになって、レスポンスを返すまで2秒かかる。 これが1秒ならまだいいが、普通、処理待ちをしている間にもどんどんリクエストは来るので、雪だるま式に処理待ちのリクエストが増えていくことだろう。 なので、同期処理が必要ない部分は、積極的に非同期処理に逃がしていかないといけない。 Background Job Workerはどれを使えばい
Task で一定数ずつ並列で外部サイトにアクセス - Qiita
Elixir(Erlang)の並列処理の威力を確かめるため、「テストサーバに外部からアクセスできないことを確認する」スクリプトを Elixir で書いてみました。 PythonやRubyなどで普通に直列で実行している場合、途中でつまるサイトがあると、タイムアウトまでそこで止まってしまいます。そういうサイトが複数あった場合にはそりゃもう大変です。並列実行することにより、変なサイトがあっても上限は最悪タイムアウトまでで済むため、精神衛生上とても良いです。しかも Elixir ならとっても簡単に書けます。 ソースコード一式は GitHub に置いてあります。 実行ファイルの作成手順 mix でプロジェクトのガワを作成 mix.exs を編集して依存ファイルをダウンロード Elixirのソースコードを書く コンパイル 実行 mix の設定 mix.exs の生成と編集
マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
Lock-freeとWait-freeアルゴリズム - Wikipedia
Lock-freeとWait-freeアルゴリズムとは、共有データにロックをかけてアクセスを防ぐアルゴリズムとは違い、複数のスレッドが同時並行的に、ある対象データを壊すことなしに読み書きすることを可能にするアルゴリズムである。Lock-free とはスレッドがロックしないことを意味しており、全てのステップにおいてシステムが必ず進行する。これはLock-free ではミューテックスやセマフォといった、排他制御のためのプリミティブを使ってはならないことを意味する。なぜならロックを持っているスレッドの実行が中断した場合、全体の進行を阻止しうるからである。Wait-free とは、他のスレッドの動作に関係なく、スレッドがいかなる操作も有限のステップで操作を完了させられることを指す。あるアルゴリズムがLock-freeであるがWait-freeでないことはありうる。Wait-free なアルゴリズム
共有メモリ - Wikipedia
3つのプロセッサによる共有メモリシステムの図。 複数のプログラム間の通信手段として使う場合と、単に複製を用意する冗長さを防ぐ目的の場合などがある。共有メモリはプログラム間でデータをやりとりする効率的手段である。文脈によって、それらプログラムが単一のプロセッサ上で動作する場合と複数の異なるプロセッサ群上で動作する場合がある。単一のプログラムの内部でメモリを使って通信する場合もあり、例えばマルチスレッドが典型的だが、仮想空間をもともと共有している場合は「共有メモリ」とは呼ばない。 コンピュータのハードウェアによる共有メモリは、マルチプロセッサシステムにおける複数のCPUがアクセスできるRAMの（通常）大きなブロックを意味する。 共有メモリシステムでは、全プロセッサがデータを共有しているためプログラミングが比較的容易で、同じメモリ位置へのアクセスによって高速なプロセッサ間通信が可能である。問題は
グローバルインタプリタロック(GIL)とは
LL言語がマルチプロセッサ環境のメリットを捨ててまでグローバルインタプリタロックを採用している理由について調べてみた。 その為にはプロセスとスレッドについての前提知識がけっこう必要だったので、ついでにざっくり調べてみた。 LL言語がマルチプロセッサ環境のメリットを捨ててまでGILを実装している理由 結論を先に書くと、LL言語がマルチプロセッサ環境のメリットを捨ててまでGILを実装している一番の理由は、「スレッドセーフではないCで書かれたモジュールをたくさん使っているから」ということになるっぽい。 この結論に至るまでの色々な前提知識についても書いておく。 プロセスとスレッド プロセスとスレッドの特徴をざっくり対比させて書くとこんな感じになる。 ユーザースレッドとカーネルスレッド ユーザースレッド ユーザ空間で実装されたスレッド機構をユーザースレッドと呼ぶ。 1つのプロセス内の複数のスレッドは
Benjamin Tan's Learnings & Writings - Implementing Parallel Comprehension with Elixir Macro Goodness
Ruby の Monitor と ConditionVariable の使い方 - Mame the hack
Ruby の Monitor と ConditionVariable の使い方 なかなかぐぐっても日本語の資料が見つからなかったので自分で動かしてみた。(ぐぐる能力低い) まずThreadの直列化 require "thread" require "monitor" moni = Monitor.new val = 0 Thread.new { 3.times { puts "thread1 start: #{val}" val+=1 sleep 0.1 puts "thread1 end: #{val}" } } Thread.new { 3.times { puts "thread2 start: #{val}" val+=1 sleep 0.1 puts "thread2 end: #{val}" } } sleep 結果は以下の通り。 start > end, start > en
PostgreSQL のトランザクション & MVCC & スナップショットの仕組み
このページでは PostgreSQL のトランザクション(Transaction)、Multi Version Concurrency Control(MVCC)、スナップショット(Snapshot)の仕組みを説明する。 PostgreSQL の他の記事へのインデックスはここ。 更新履歴 (2016.04.30) 作成。 (2016.09.16) データ定義言語(DDL)のトランザクションを追加。 (2016.09.28) データ定義言語(DDL)の MVCC アンセーフ動作を追加。 (2017.04.07) Combo Command ID の説明が間違っているのを修正。 目次 1. はじめに 2. トランザクション分離レベル(Transaction Isolation Level) 3. Serializable 以外の分離レベルの実現方法 3.1 トランザクションとと可視性(Visi
)
モニタ (同期) - Wikipedia
この記事には参考文献や外部リンクの一覧が含まれていますが、脚注による参照が不十分であるため、情報源が依然不明確です。適切な位置に脚注を追加して、記事の信頼性向上にご協力ください。（2019年3月） 並行計算の分野におけるモニタ（英: monitor）とは、共有オブジェクトの状態が複数のスレッドから同時にアクセスされることを防ぎ、かつ状態が変化するまで待機させるような、同期のための構成概念である。モニタはスレッドに、排他アクセス権を再取得してタスク（英語版）を再開する前に、特定の条件が満たされるまで待機するために、排他アクセス権を一時的にあきらめさせるメカニズムを提供する。モニタはミューテックス（ロック）と、少なくとも1つの条件変数（英: condition variable）から成る。条件変数は、オブジェクトの状態が変化したときに明示的にシグナルされ、このときミューテックスは条件変数を待機
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Concurrent Programming — Erlang System Documentation v27.0
Preemptive scheduling of Erlang NIFs
You're Smart Enough for Elixir
Partial Downloads with Enumerators and Fibers
Class: Monitor (Ruby 2.1.2)
Class: MonitorMixin::ConditionVariable (Ruby 2.1.2)
Module: MonitorMixin (Ruby 2.1.2)
Benchee 0.3.0 released – formatters, parallel benchmarking & more