この記事はC++ Advent Calendar 2014の21日目にエントリしています。 内容はC++メモリモデルと逐次一貫性についての概説記事となっています。 flickr / nomadic_lass もくじ 忙しい人のための「C++メモリモデル」 C++メモリモデル一問一答 ソフトウェアからみた「C++メモリモデル」 “メモリ”という共有リソース C++ソースコードが実行されるまで メモリの一貫性と整合性 逐次一貫性モデル is Easy ハードウェアからみた「C++メモリモデル」 ハードウェア・メモリ一貫性モデル C++コンパイラの責任と自由 強いメモリモデル vs. 弱いメモリモデル 逐次一貫性モデル is Hard (本文のみ約9600字) まえがき When your hammer is C++, everything begins to look like a thumb
1台の物理サーバ上で複数のDockerコンテナが稼働する環境では、限られたハードウェア資源の利用制限は非常に重要です。 特定のユーザーが使用するコンテナがホストマシンのハードウェア資源を食いつぶすようなことがあれば、他のユーザーのハードウェア資源の利用に支障をきたします。 こうしたことを防ぐためにDockerでは、CPU、メモリ、ディスク、ネットワーク等の資源を管理する仕組みが備わっています。 今回はCPUとメモリの利用制限の方法を紹介したいと思います。 DockerのCPU資源管理 Dockerは、1つのCPUコアを複数のコンテナで利用しますが、そのCPUを割り当てる時間の割合をコンテナ実行時に指定するという方法を採っています。そしてコンテナにはCPUの割当時間の割合を示すための相対値が与えられています。 CPUの資源管理の例 それぞれのコンテナのCPUの相対値には、標準では1024とい
This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Build 21364 For general Windows information on build 21364 visit the Windows blog. GUI apps are now available! For more information see this blog post. Resolve error when accessing files via \\wsl.localhost\. Fix potential deadlock in LxssManager service
時事ネタ いや、「今、fj.comp.lang.cが熱い!」という話は ちょっと前から聞き及んではいたのですが、 流量が尋常じゃないらしいので、 忙しさもあって読むのを控えていたんですけど、 先日、大筋を拾い読みしてみました。 確かに熱いですねえ。 いったん収束するかなあ、と思ったら、なんかまた泥沼の気配が(^^; fjを読んでない人のために説明すると(って、 私も普段はあんまり読んでないんですが)、 「malloc()で確保した領域は、必ずfree()で解放しなきゃいけないか?」という 話題でして、「exit()する時には、OSが解放してくれるんだから 別にfree()しなくてもいいじゃん」という主張と、 「いや、malloc()には常に対になるfree()があるべきだ」という主張があって、 議論を呼んでいたのでした。 んで、私がどう思うかなんですが、 私は面倒臭がりなので、free()
C++のメモリ確保と解放について調べてみた。 入手先 スタック領域とヒープ領域 項目 スタック ヒープ 管理者 OS・コンパイラ プログラマ 生存期間 関数終了・デストラクタまで delete・freeされるまで 変数サイズ コンパイル時点で固定 実行時に動的 メモリ総量 少ない 多い 確保 int v; int v = new int(); 解放 (宣言した関数終了時に自動解放) delete v; 変数を宣言する方法が違う スタック領域は少ないため、多く確保してしまうとスタックオーバーフローを起こしてしまう。 メモリ確保 メモリ確保にはおおよそ2種類の方法がある。 自動変数によるスタック領域のメモリ確保 newやmallocによるヒープ領域のメモリ確保 int value; 上記のコードは自動変数と呼ぶ。 OSやコンパイラがメモリの確保と解放を行ってくれる。 スタック領域に確保される。
ユークエスト株式会社は2021年10月1日をもちまして、 株式会社東光高岳に吸収合併を致しました。 Webサイトは下記のURLに移転しました。 https://uquest.tktk.co.jp/ ※5秒後に移転先にジャンプします。
こんにちは。田原です。 前回までに説明したプログラム用メモリ、静的変数用メモリ、スタック用メモリは、基本的にコンパイル時にサイズが決まります。もし、これらの領域しか使わない場合、巨大なメモリを搭載しているコンピュータでプログラムを走らせても、その巨大なメモリを有効活用できません。それは悲しいですよね。 その巨大なメモリをうまく使うための仕組みが「ヒープ用メモリ」です。今回は、このヒープとその使い方について解説します。 第4回目 コンピュータの仕組みについてで、メモリとそのアドレス、そしてポインタについて少し説明しました。これらはたいへん重要ですので、軽く復習します。 int a; int* b=&a; 上記のようにint型の変数aがあったとします。その変数aはどこかのメモリ上に割り当てられますので、アドレスが割り振られています。その先頭アドレスを取り出す演算子が & でした。つまり、 &a
どうも、今週はセキュリティ関連の講座に出ており、朝から晩までずっと教室に缶詰の状態でした。 本来参加しようとすると非常に高額な参加費が取られるのですが、学生枠ということで無料で参加させて頂きました。 講義の内容などを記事にはしたいと思うのですが、内容は喋ってはいけないという約束なので話せないです。 とりあえず、自分のセキュリティの勉強として「バッファオーバーラン」くらい起こしてみようと思って試行錯誤してみましたが、ちょっと知識不足でした。 来週までには任意のコードが入力を通してOS側にぶち込めるように出来たらいいな、と思うが出来なかったら考える。 プログラムの基本的な動作 基本的なプログラムを実行するデータ構造は以下のようになっている。 IPA/ISEC から引用 この画像の様に、プログラムの実行コード自体はコンパイル時に計算され、実行時には仮想メモリ領域の先頭に配置される。 その後、ne
とりあえず動くプログラムを書く ここでは例として、Fooという構造体の2次元配列を、引数で指定された幅と高さで作る、createFooMatrixという関数を作ってみます。 なお、配列の各要素を、initializeFoo関数で初期化しています。 Foo **createFooMatrix ( int width, int height ) { Foo **ptr = NULL; int w, h; ptr = (Foo **)malloc(height * sizeof(Foo *)); for (h = 0 ; h < height ; h++) { ptr[h] = (Foo *)malloc(width * sizeof(Foo)); for (w = 0 ; w < width ; w++) { initializeFoo(&ptr[h][w]); } } return ptr;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く