『詳解Rustアトミック操作とロック』（Rust Atomics and Locks） - Don't Repeat Yourself
昨年買っていたんですが、年末年始の時間を使って少し読めました。 著者はRustコンパイラにコントリビューションをしたことがあれば誰でも知っているかもしれない、Mara Bos氏です。 ちなみにですが、原著は下記サイトで無料でも読むことができます。 marabos.nl 書籍は下記です。 詳解 Rustアトミック操作とロック ―並行処理実装のための低レイヤプログラミング 作者:Mara Bosオーム社Amazon なおこの記事内で「本書」と明記する場合、それは『詳解Rustアトミック操作とロック』を指します。また、「筆者」は私自身のことであり、「著者」はMara Bos氏のことです。 内容のメモ 1章 2章 3章 4章、5章 6章 Miri Loom 7章 8章 9章 10章 感想 日本語での別の資料 内容のメモ 読んだ内容のうち、印象に残ったり初見だったものをメモしておきます。 1章 1章
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！ - Qiita
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離
PHP5.3.2以降ではfcloseで自動的にアンロックされない
PHPの本家サイトでflockの説明を読んでいたら、以下の変更履歴に気がつきました。 5.3.2 ファイルのリソースハンドルを閉じたときにロックを自動的に解放する機能が削除されました。 ロックの解放は、常に手動で行わなければなりません。 http://php.net/manual/ja/function.flock.php ところがネットの解説を見ると、ロック開放はflock($fp, LOCK_UN); ではなく、fcloseでやれとしている解説が結構あります。 (4)fcloseの前にflock解除するな … fcloseの前にflock(ファイルポインタ, LOCK_UN) する人は実に多いのですが、これははっきりと間違いだと断言します @ITのPHPの記事が突っ込みどころ満載 - 暴言満載 LOCK_UNは普通は使われない。ロック開放はfclose()関数でやるのが鉄則。 http
Pthread - Mutexでプロセス間排他制御を行う - s-kita’s blog
使用するシステムコール、API Mutex関連 #include <pthread.h> int pthread_mutex_init( pthread_mutex_t *mutex, const pthread_mutexattr_t *attr); int pthread_mutex_lock(pthread_mutex_t *mutex); int pthread_mutex_unlock(pthread_mutex_t *mutex); int pthread_mutex_destroy(pthread_mutex_t *mutex); Mutex属性関連 #include <pthread.h> int pthread_mutexattr_init(pthread_mutexattr_t *attr); int pthread_mutexattr_destroy(pthread_
開発メモ: ロック自作による高速化
マルチスレッドのロック機構を自作してKyoto Cabinetを高速化したよという話。 背景 以前の記事にも書いたとおり、組み込みのrwlockはmutexに比べても遜色ない速度で動作して素敵なのだが、実はロック処理自体の並列性があんまり高くないんじゃないかなぁと思い始めてきた。というか、pthreadのロック機構は遅い（期待ほど速くない）んじゃないかなぁと感じる今日この頃。 特にspin lock（pthread_spinlock_t）とrwlock（pthread_rwlock_t）が遅い気がしている。プロファイルをとると、Kyoto Cabinetの実行時間の多くをロック回りの処理が占めているので、こいつらを自作のロックに置き換えて軽量化してみよう。pthreadのロックプリミティブはPOSIXの規程に基づいたいろんな機能を備えているが、自分で作れば自分のユースケースに必要な機能だけ
サーバーマシン1台で同時接続者数1万名を実現するにはどうすればいいのかというノウハウと考え方
CEDEC 2012ではドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？ということで、オンライン作品であるドラクエXを支えるサーバの構成が講演されましたが、ゲームサーバー＆ネットワークエンジン「ProudNet」の開発者であるNettention社のCEOであるHyunjik Baeさんは、韓国のオンラインゲームのサーバー開発と利用の経験を通して大規模プレイヤーのためのリアルタイムネットワーク同期技術について講演しました。 サーバーマシン１台でMMO同時接続者数10,000名を実現する方法 | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/AB/C12_I0284.html Hyunjik Bae： こんにち
ロックフリープロトコル
共有変数へのアクセス 異なるコンテキスト間で共有変数を利用してデータ交換を行うことはしばしば行われます。変数がＣＰＵの１命令でアクセスできる（atomicな）もの１つだけであれば問題は生じませんが、構造体などを渡たそうとした場合などには問題が生じます。片方のコンテキストでデータを読み込んでいるときにもう片方のコンテキストでデータを書き換えてしまい、データの整合が取れなくなってしまう可能性があるからです。そこで通常はこれらの変数へのアクセスをクリティカルセクションで行うようにします。 しかし、クリティカルセクションが利用できない場合もあります。それは割り込みルーチンから直接共有変数を書き換えたい場合です。割り込みルーチンのような非タスク部からは待ち状態に入る可能性のあるシステムコールは呼べませんから、クリティカルセクションを作って共有を管理することができなくなります。そういう場合は読み出し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
はてなブログ | 無料ブログを作成しよう
2004年11月号目次