はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自

まえがき クラウド上の仮想サーバから手元のスマートフォンまで、いまや複数のCPUコアを搭載するマルチコアはどこにでもある環境になりました。ハードウェア側が並列(Parallel)・並行(Concurrent)処理に向けて急速に進化する一方で、ソフトウェア側つまりプログラミング言語の進化はさほど追い付いていません。並行処理記述の手軽さを求めた Go言語 や、マルチスレッド処理の安全性を重視する Rust言語 などが登場してはいるものの、「普通にプログラムを記述するだけで複数CPUコア環境で高速に走るプログラミング言語」は遠い夢物語のままです。 モダンなプログラミング言語や並列・並行処理ライブラリは、複雑で難解なマルチスレッド処理を直接記述しなくてすむよう、安全性・利便性の高い抽象化レイヤを提供します（例：Go言語のgoroutineとchannel、Rust言語の Rayonライブラリ）。し

『Ruby でつくる Ruby』などでお世話になっているラムダノートが、新しい雑誌「n月刊ラムダノート」を創刊しました。 www.lambdanote.com コンピュータ関係の技術情報の記事だけが載るそうです。創刊号は、『TCPの再送制御機構』、『「コルーチン」とは何だったのか？』、『MLOpsの歩き方』、の 3 本です。 『TCP の再送制御機構』は、パケットを送ってから返事が来るまでの RTT (Round-Trip Time) を計測する方法や、RTT を使った再送のアルゴリズムや、RTT を使わない再送のアルゴリズムなど、TCP の再送に関する仕様・実装の歴史から最新提案までを、日本語話者の中では間違いなく世界一詳しい第一人者である西田佳史さん（@nsd）が広く深く紹介しています。 『「コルーチン」とは何だったのか？』は、ぼくが書きました。伝統的なコルーチンの説明から、JavaS

以下は、いつも通り、私のざっくりな調査内容をまとめるものだから、もし、内容に誤りがあったら報告してほしい。(想像も含むので) 前提目的としては、akkaベースのウェブフレームワーク(sprayかakka-http)で、複数のリクエストを同時に受けた時にサーバのCPUをフル活用するためにはどうすることである。 フル活用とは、あるスレッドがIOなどで寝た場合、他のタスクにCPUを割り当てて、CPUを使う処理を常に全力で実行することである。こうすると、最善では、結果的に全タスクを処理する時間は、全計算を行った時間まで短縮出来る。こういうテクニックは、GPUにおいてメモリ転送と計算をオーバーラップさせてメモリ転送を償却する形でも用いられる。 さて、ウェブフレームワークは何らかのポートにbindして、そこからリクエストを捌く。akkaでは、この時のスレッドの割当方法をdispatcherなりExec

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? まあ例を挙げて話したほうがわかりやすい気がするので例をあげると、たとえばあなたはオンプレミスからコンテナまで総計数千台のホスト的な何かで構成されたシステムを管理する必要があります、と。この規模になってくると当然日々何かが壊れては何かが直っていくのはそういうものですね。で、じゃあ、刻一刻と変わる管理台帳と実際の環境の整合性をチェックすることを考える、と。すると要件としては、 管理台帳から存在するはずのホスト名とそのIPアドレスの一覧を引っ張ってくる そこからまずホスト名をババババと名前解決して管理台帳どおりのIPアドレスが解決されるか確認

2. 自己紹介 • 野島 裕輔 • KMC ID: nojima • Github: nojima • Twitter: nojima • サイボウズ株式会社でインフラ開発をやっています。 • nginx のパッチを書いて DoS 対策したり SSL セッションキャッシュをホスト間で共有したり • サーバクラスタの管理ツールを作ったり • 矢印が判定ｴｧﾘｱに重なるﾀｧｰｲﾐﾝｸﾞで左のﾊﾟｧｰﾉｩを踏むッ!!

C++11標準ライブラリにおいて const, mutable キーワードが持つセマンティクスと、自作クラスのスレッド安全性に関するイディオムについてメモ。本記事の内容はC++ and Beyond 2012でのHerb Sutter氏プレゼン "You Don't Know const and mutable" に基づく。 要約： C++98/03：constメンバ関数はオブジェクトに対して「logical const（論理的const）」な操作であることを意味する。constメンバ関数ではmutableメンバ変数の変更操作を含む可能性があるが*1、クラス外部から観測する限りはconst（不変操作）のように振る舞う。 C++11以降：C++03以前のセマンティクスに加えて、「同一オブジェクトのconstメンバ関数を複数スレッドから同時に呼び出してもよい」というスレッド安全性を表明する。標

多くのプログラミング言語では、マルチスレッド処理向け同期プリミティブとして「ミューテックス(mutex)」と「条件変数(condition variable)」を提供しています*1 *2。ミューテックスは排他制御機構として有名ですし、その動作もロック(lock)／アンロック(unlock)と比較的理解しやすいため、不適切に利用されるケースはあまり無いと思います*3。一方、条件変数の動作仕様はしばしば誤解され、不適切な利用による並行性バグに悩まされるケースが多いようです。 本記事では、スレッドセーフなFIFO(First-In-First-Out)キューを段階的に実装していく事例を通して、条件変数の適切な使い方について説明していきます。例示コードではC++11標準ライブラリを用いますが、Pthreads(POSIX Threads)やC11標準ライブラリへは単純に読み替え可能です（→Pthr

勉強会での発表 先日Sapporo.cppとCLR/Hの合同勉強会を開催し、 僕はC++11のスレッドについて紹介をしました。 規格書で読むC++11のスレッド from Kohsuke Yuasa この発表では、C++11で導入されたスレッドライブラリの中から、 thread mutex/lock future/promise condition_variable について、それぞれがどんなものかを紹介し、また、それらの機能を使用して簡単なタスクライブラリを作ったという話をしました。 実際のセッションでは、発表時間が足りなくなってしまい、ちゃんとこのhwm.taskを紹介できなかったので、ちょっと残念だったのと、 あと、当日発表したときは未完成なところや微妙なところがもあり、それからもう少し手を加えたりしたので、改めてこのブログで紹介したいと思います。 hwm.task GitHub -

この記事はC++ Advent Calendar 2013の15日目にエントリしています。 内容はC++標準ライブラリとスレッドセーフに関する解説になります。 flickr / rennasverden もくじ What's スレッドセーフ？ スレッドセーフという幻想 基本型とデータ競合 C++標準ライブラリとデータ競合 C++標準ライブラリ：シーケンスコンテナ編 C++標準ライブラリ：連想コンテナ編 スレッドセーフ RELOADED 基本的なスレッドセーフ保証 std::shared_ptr<T> std::rand() std::cout （本文のみ約9000字） はじめに マルチスレッド対応の点では他言語に遅れを取っていたプログラミング言語C++ですが、C++11ではようやく標準ライブラリにスレッドサポートが追加されました。C++11スレッドサポートではスレッドクラスstd::thr

プログラミング言語C++のvolatile変数がスレッド間の同期機構として機能するか否かという論点について、有りそうな質問とその答えについての簡易メモ。（自身の思考整理用） 結論：このプログラムは可搬性が無く、未定義動作(undefined behavior)を引き起こす。C++11ではvolatile変数でなくatomic変数を用いるべき。C++03以前ではコンパイラ依存の仕組みを利用する。 volatile int running = 1; // 処理スレッド void another_thread() { while (running) { // ??? //... } } // 制御側スレッド void main_thread() { //... running = 0; // ??? } C++言語仕様ではどう定義される？(C++03以前) C++03以前のC++言語仕様ではそも

C++11標準ライブラリが提供する機能とスレッド安全性(thread safety)についてのメモ*1。C++03以前では処理系依存。 要約：C++標準ライブラリのオブジェクトでは、少なくとも言語組み込みint型と同様のスレッド安全性を提供する。 基本的なスレッド安全性 C++標準ライブラリが提供するオブジェクトは、個々の関数動作仕様で特記されるケースを除いて、下記の基本的なスレッド安全性を保証する。 異なるスレッド上における異なるオブジェクトに対する操作はデータ競合を引き起こさない。*2（1.10, 17.6.5.9/p2-4） 異なるスレッド上における同一オブジェクトに対する操作は、全スレッドがreadアクセスのみであればデータ競合を引き起こさない。少なくとも一方が変更操作を行う場合はデータ競合を引き起こす。*3 *4（1.10） 明に要求している場合を除いて、引数やコンテナ要素が間接

鉄則3: マルチスレッドのプログラムでのforkはやめよう マルチスレッドのプログラムで、「自スレッド以外のスレッドが存在している状態」でfork*1を行うと、さまざまな問題を引き起こす可能性があります。「問題」の典型例としては、子プロセスのデッドロックが挙げられます。問題の詳細を把握しないまま、マルチスレッドのプログラムで不用意にforkするのはやめましょう！ 何が起きるか 実例から見てみましょう。次のコードを実行すると、子プロセスは実行開始直後のdoit() 呼び出し時、高い確率でデッドロックします。 void* doit(void*) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); struct timespec ts = {10, 0}; nanoslee

「Java セキュアコーディング 並行処理編」 「Java セキュアコーディング 並行処理編」（原著 CERT/CC「Java Concurrency Guidelines」）は、カーネギーメロン大学ソフトウエア工学研究所の CERTプログラムと Oracle の共同作業の成果である「CERT Oracle Secure Coding Standard for Java」の中から、次のカテゴリに含まれる並行処理プログラミングに関連したガイドラインをまとめた資料です。 可視性とアトミック性(VNA) ロック(LCK) スレッドAPI(THI) スレッドプール(TPS) スレッドの安全性に関する雑則(TSM) セキュアな Java マルチスレッドプログラミングに取り組む際の手引きとしてご活用ください。 本資料に記述されたガイドラインを含む「CERT Oracle Secure Coding S

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.