BDS2006で開発中の自作プログラムにおいて、時間のかかるロード部分をマルチスレッド化した所、特定の環境でよく落ちるようになってしまいました。
調べてみると iostream (あるいはその中で使っている locale?)に問題があるような気がしています。
具体的には、BDS2006で下記プログラムをビルドし、論理プロセッサ数が2以上の PC で実行すると落ちることがあるようです。
(VisualStudio2005, C++Builder6 でビルドしたものはまったく問題ないのに…)
同様の現象に遭遇されたことのある方、回避方法をご存知の方がおられましたら教えて頂けると嬉しいです…。
(下記プログラムがスレッドセーフじゃない、というツッコミも歓迎です)
落ちたPC(まれに落ちないこともある)
- Pentium4 2.4CGHz(FSB800MHz, HyperThreading有効)
- CoreDuo L2300(1.5GH)
落ちなかったPC
- Pentium4 2.4BGHz(FSB533MHz, HyperThreading非対応)
(タブが効かないようなので、下記ソースは全角スペースでインデントしています)
−−−ここから−−−ここから−−−ここから−−−
#include <windows.h>
#include <iostream>
#include <sstream>
HANDLE g_handleThread = 0;
DWORD WINAPI processThread(LPVOID pParam)
{
{
std::wostringstream osstr;
for (unsigned int i = 0; i < 100000; i ++) {
osstr << i * 2 << L" " << std::endl;
}
}
return 0;
}
int main(int argc, char* argv[])
{
std::locale::global(std::locale(std::locale::classic(), "", std::locale::ctype));
DWORD idThread = 0;
g_handleThread = ::CreateThread(NULL, 0, processThread, NULL, 0, &idThread);
{
std::wostringstream osstr;
for (unsigned int i = 0; i < 100000; i ++) {
osstr << i << L" " << std::endl;
}
}
if (g_handleThread) {
::WaitForSingleObject(g_handleThread, INFINITE);
::CloseHandle(g_handleThread);
g_handleThread = 0;
}
return 0;
}
−−−ここまで−−−ここまで−−−ここまで−−−
調べてみると iostream (あるいはその中で使っている locale?)に問題があるような気がしています。
具体的には、BDS2006で下記プログラムをビルドし、論理プロセッサ数が2以上の PC で実行すると落ちることがあるようです。
(VisualStudio2005, C++Builder6 でビルドしたものはまったく問題ないのに…)
同様の現象に遭遇されたことのある方、回避方法をご存知の方がおられましたら教えて頂けると嬉しいです…。
(下記プログラムがスレッドセーフじゃない、というツッコミも歓迎です)
落ちたPC(まれに落ちないこともある)
- Pentium4 2.4CGHz(FSB800MHz, HyperThreading有効)
- CoreDuo L2300(1.5GH)
落ちなかったPC
- Pentium4 2.4BGHz(FSB533MHz, HyperThreading非対応)
(タブが効かないようなので、下記ソースは全角スペースでインデントしています)
−−−ここから−−−ここから−−−ここから−−−
#include <windows.h>
#include <iostream>
#include <sstream>
HANDLE g_handleThread = 0;
DWORD WINAPI processThread(LPVOID pParam)
{
{
std::wostringstream osstr;
for (unsigned int i = 0; i < 100000; i ++) {
osstr << i * 2 << L" " << std::endl;
}
}
return 0;
}
int main(int argc, char* argv[])
{
std::locale::global(std::locale(std::locale::classic(), "", std::locale::ctype));
DWORD idThread = 0;
g_handleThread = ::CreateThread(NULL, 0, processThread, NULL, 0, &idThread);
{
std::wostringstream osstr;
for (unsigned int i = 0; i < 100000; i ++) {
osstr << i << L" " << std::endl;
}
}
if (g_handleThread) {
::WaitForSingleObject(g_handleThread, INFINITE);
::CloseHandle(g_handleThread);
g_handleThread = 0;
}
return 0;
}
−−−ここまで−−−ここまで−−−ここまで−−−
|
|
|
|
コメント(52)
高橋です
------------------------------------------
std::ostringstream oss;
oss << "123456789012345678901234567890123";
------------------------------------------
だとCodeGuardがエラーを報告するけど
------------------------------------------
std::ostringstream oss;
oss << "12345678901234567890123456789012";
------------------------------------------
は問題無いみたいですね... 不思議です
------------------------------------------
std::ostringstream oss;
oss << "123456789012345678901234567890123";
------------------------------------------
だとCodeGuardがエラーを報告するけど
------------------------------------------
std::ostringstream oss;
oss << "12345678901234567890123456789012";
------------------------------------------
は問題無いみたいですね... 不思議です
>檜木さん
>・iostream を使うなら API の CreateThread は実はＮＧで_beginthread 等を使わないと正しい初期化が行われない？
うっ、これは根本的な問題ですね…。
まずはこちらに書き換えて試してみます。
言い訳にもなりませんが、マルチスレッド化の作業時は VC8 のヘルプを見ながら書いていて、そこで C ランタイムライブラリに限る(→C++ランタイムは無関係)と勘違いしていたようです…。
iostream に float を食わせた時の CodeGuard 問題は
BDS2006 トピックで書いておられましたね。
> ken さん
サポート料、調べて頂きありがとうございました。(すみません、やはり零細企業には手が出そうにないです…。orz)
>・iostream を使うなら API の CreateThread は実はＮＧで_beginthread 等を使わないと正しい初期化が行われない？
うっ、これは根本的な問題ですね…。
まずはこちらに書き換えて試してみます。
言い訳にもなりませんが、マルチスレッド化の作業時は VC8 のヘルプを見ながら書いていて、そこで C ランタイムライブラリに限る(→C++ランタイムは無関係)と勘違いしていたようです…。
iostream に float を食わせた時の CodeGuard 問題は
BDS2006 トピックで書いておられましたね。
> ken さん
サポート料、調べて頂きありがとうございました。(すみません、やはり零細企業には手が出そうにないです…。orz)
_beginthread や _beginthreadex に変更して試してみましたが、やはり落ちる状況は変わりませんでした。orz
今晩にでもソースをアップしておきます。
残る可能性については、
>檜木さん
> ・BDS2006でのSTL入れ替えに伴う問題
> ・暗黙のうちに使われている Allocator がマルチスレッド動作に対応していない
Allocator がマルチスレッド非対応なら、STL 周りは全滅ですね…。(泣)
もう Borland による修正を待つくらいしかできる事はなさそうです…。
> ・マルチスレッド対応のRTL にリンクされていない
VC++ ならばよく聞く話なので、最初にまずこれを疑い
BDS2006 のオプションを探しまわったのですが、
見つけられませんでした…。orz
リンカオプションのコマンドラインをみる限りは、cw32mt.lib をリンクしているようなので、問題はなさそうなのですが…。
今晩にでもソースをアップしておきます。
残る可能性については、
>檜木さん
> ・BDS2006でのSTL入れ替えに伴う問題
> ・暗黙のうちに使われている Allocator がマルチスレッド動作に対応していない
Allocator がマルチスレッド非対応なら、STL 周りは全滅ですね…。(泣)
もう Borland による修正を待つくらいしかできる事はなさそうです…。
> ・マルチスレッド対応のRTL にリンクされていない
VC++ ならばよく聞く話なので、最初にまずこれを疑い
BDS2006 のオプションを探しまわったのですが、
見つけられませんでした…。orz
リンカオプションのコマンドラインをみる限りは、cw32mt.lib をリンクしているようなので、問題はなさそうなのですが…。
_beginthread/_beginthreadex 版をこちらに上げました。
http://qualia.la.coocan.jp/bcb/modules/smartsection/item.php?itemid=5
現象は変わらずですので実行しても面白味はありません(^^;)。
> 檜木さん
> 念のためと思いましたが、今回は無罪のようですね。
とはいえ、使い方を誤っていた事には違いありません。
勉強になりました。ありがとうございます(_o_)
> CodeGuard 問題は私が自分で書いていました？？？
> 全然覚えていません…。がっくり…。
こちらのトピックの 43 番目が該当する記事だと
思っているのですが、勘違いしてましたらすみません(^^;)。
http://mixi.jp/view_bbs.pl?id=3147945&comm_id=76027
> Dinkumware ではここで STL とマルチスレッドに言及しています。特に参考になる感じはないのですけど…
ありがとうございます。こちらも拝見しております。
Dinkumware 自体は マルチ/シングルスレッド両対応で
セットアップスクリプトで設定可能なものの、
デフォルトはマルチスレッドの方だとありますね…。
yval.h でオプションを設定可能とあるので、
ちょっとそれらしい define をいじってみましたが、
上のサンプルが落ちなくなる組み合わせを見つけることが
できませんでした…。
今後の話ですが、だんだん打つ手ナシになってきましたので、
QualityCentral の成り行きを見守りつつ、
しばらくお仕事ソースのスレッド対応は凍結しようかと考えています。
現状で唯一明確な解決策というのは「STL からの脱却」かと
思いますが、現状のコードは依存しまくっているため
修正の手間が馬鹿にならないのです…。
(皆さんに良くして頂いたのに、ヘタレな結論で本当にスミマセン… orz)
http://qualia.la.coocan.jp/bcb/modules/smartsection/item.php?itemid=5
現象は変わらずですので実行しても面白味はありません(^^;)。
> 檜木さん
> 念のためと思いましたが、今回は無罪のようですね。
とはいえ、使い方を誤っていた事には違いありません。
勉強になりました。ありがとうございます(_o_)
> CodeGuard 問題は私が自分で書いていました？？？
> 全然覚えていません…。がっくり…。
こちらのトピックの 43 番目が該当する記事だと
思っているのですが、勘違いしてましたらすみません(^^;)。
http://mixi.jp/view_bbs.pl?id=3147945&comm_id=76027
> Dinkumware ではここで STL とマルチスレッドに言及しています。特に参考になる感じはないのですけど…
ありがとうございます。こちらも拝見しております。
Dinkumware 自体は マルチ/シングルスレッド両対応で
セットアップスクリプトで設定可能なものの、
デフォルトはマルチスレッドの方だとありますね…。
yval.h でオプションを設定可能とあるので、
ちょっとそれらしい define をいじってみましたが、
上のサンプルが落ちなくなる組み合わせを見つけることが
できませんでした…。
今後の話ですが、だんだん打つ手ナシになってきましたので、
QualityCentral の成り行きを見守りつつ、
しばらくお仕事ソースのスレッド対応は凍結しようかと考えています。
現状で唯一明確な解決策というのは「STL からの脱却」かと
思いますが、現状のコードは依存しまくっているため
修正の手間が馬鹿にならないのです…。
(皆さんに良くして頂いたのに、ヘタレな結論で本当にスミマセン… orz)
檜木さん、お気遣いありがとうございます。(_o_)
STLport を入れてみるというのは気づきませんでした。
ちょっと作業的に重そうですが(^^;)後で試してみたいと思います。
仕事締切のプレッシャーから逃れられたので、あれからボチボチ調査していますが、今のところ VisualStudio2005 の Dinkumware と BDS2006 の Dinkumware の違いに注目しています。
VS2005は
- コピーライトが 2005年
- C の関数のラッパ(cmathなど)も Dinkumware
BDS2005は
- コピーライトが 2003年
- C の関数のラッパは Borland 製
という違いがあるので、互いにソースを比較して2 年間の間に修正された所や、C 関数のラッパを呼び出している所に着目しています。
並行してデバッガ上での動作も見ていますが、落ちるタイミングが locale オブジェクトの解放時に集中しているようです。そこでリファレンスカウンタを上げ下げしているので lock し忘れかも…と思うのですが確証はまだありません。
また何かわかったら書き込みます。
STLport を入れてみるというのは気づきませんでした。
ちょっと作業的に重そうですが(^^;)後で試してみたいと思います。
仕事締切のプレッシャーから逃れられたので、あれからボチボチ調査していますが、今のところ VisualStudio2005 の Dinkumware と BDS2006 の Dinkumware の違いに注目しています。
VS2005は
- コピーライトが 2005年
- C の関数のラッパ(cmathなど)も Dinkumware
BDS2005は
- コピーライトが 2003年
- C の関数のラッパは Borland 製
という違いがあるので、互いにソースを比較して2 年間の間に修正された所や、C 関数のラッパを呼び出している所に着目しています。
並行してデバッガ上での動作も見ていますが、落ちるタイミングが locale オブジェクトの解放時に集中しているようです。そこでリファレンスカウンタを上げ下げしているので lock し忘れかも…と思うのですが確証はまだありません。
また何かわかったら書き込みます。
私の日記にも書きましたが、以下ビルドする手順です
STLport 5.1.0 RC2 を C++Builder2006(BDS2006) でビルドする手順
1) STLport-5.1.0-RC2.zip を C:\STLport-5.1.0 に展開
2) mingw32-make-3.80.0-3.exe を C:\STLport-5.1.0\mingw にインストール
3) mingw32-make.exe を gmake.exe にリネーム(好みの問題)
4) コマンドプロンプトを開く
5) 環境変数PATHを限定する
set PATH=C:\STLport-5.1.0\mingw\bin;C:\Borland\BDS\4.0\Bin;C:\WINDOWS\system32
6) 環境変数INCLUDEを指定する
set INCLUDE=C:\Borland\BDS\4.0\include
7) ilink32.cfg の先頭付近に C:\Borland\BDS\4.0\lib\psdk を追加する
-L"C:\Borland\BDS\4.0\lib\psdk";"C:\Borland\BDS\4.0\lib";"C:\Borland\BDS\4.0\lib\obj";"C:\Borland\BDS\4.0\lib\release";"C:\Borland\BDS\4.0\lib\Indy10"
8) C:\STLport-5.1.0\build\lib に移動する
9) 設定を行う
configure.bat -c bcc --rtl-dynamic
10) ビルドしてインストールする
gmake -fbcc.mak install
11) C:\STLport-5.1.0\bin にdll一式、C:\STLport-5.1.0\lib にlib一式が生成される
STLport 5.1.0 RC2 を C++Builder2006(BDS2006) でビルドする手順
1) STLport-5.1.0-RC2.zip を C:\STLport-5.1.0 に展開
2) mingw32-make-3.80.0-3.exe を C:\STLport-5.1.0\mingw にインストール
3) mingw32-make.exe を gmake.exe にリネーム(好みの問題)
4) コマンドプロンプトを開く
5) 環境変数PATHを限定する
set PATH=C:\STLport-5.1.0\mingw\bin;C:\Borland\BDS\4.0\Bin;C:\WINDOWS\system32
6) 環境変数INCLUDEを指定する
set INCLUDE=C:\Borland\BDS\4.0\include
7) ilink32.cfg の先頭付近に C:\Borland\BDS\4.0\lib\psdk を追加する
-L"C:\Borland\BDS\4.0\lib\psdk";"C:\Borland\BDS\4.0\lib";"C:\Borland\BDS\4.0\lib\obj";"C:\Borland\BDS\4.0\lib\release";"C:\Borland\BDS\4.0\lib\Indy10"
8) C:\STLport-5.1.0\build\lib に移動する
9) 設定を行う
configure.bat -c bcc --rtl-dynamic
10) ビルドしてインストールする
gmake -fbcc.mak install
11) C:\STLport-5.1.0\bin にdll一式、C:\STLport-5.1.0\lib にlib一式が生成される
詳細をうちの日記に書きましたが、
Dinkumware のソースのおかげで解決策かも?というものが見つかりました。
- C:\Program Files\Borland\BDS\4.0\include\dinkumware\yyvals.h の 345行目、 _IOSTREAM_OP_LOCKS の値を 0 から 1 にする。
- C:\Program Files\Borland\BDS\4.0\source\cpprtl\readme の記述を参考に、ランタイムライブラリをビルドし直す。(Path の設定後、バッチファイルを実行するだけ)
- C:\Program Files\Borland\BDS\4.0\source\cpprtl\lib\ の下にできあがった cp32mt*.lib, cw32*.lib を C:\Program Files\Borland\BDS\4.0\Lib\ に上書きコピーする。
- 同じく cc3270*.dll を C:\WINDOWS\SYSTEM32\ に上書きコピーする。
これで問題のプロジェクトをビルドし直すと、何回実行しても落ちなくなりました。
QualityCentral のバグ報告にも追記しましたので、しっかり検証された上で次回の Update に取り込まれることを祈っています。
みなさま本当にありがとうございました!
Dinkumware のソースのおかげで解決策かも?というものが見つかりました。
- C:\Program Files\Borland\BDS\4.0\include\dinkumware\yyvals.h の 345行目、 _IOSTREAM_OP_LOCKS の値を 0 から 1 にする。
- C:\Program Files\Borland\BDS\4.0\source\cpprtl\readme の記述を参考に、ランタイムライブラリをビルドし直す。(Path の設定後、バッチファイルを実行するだけ)
- C:\Program Files\Borland\BDS\4.0\source\cpprtl\lib\ の下にできあがった cp32mt*.lib, cw32*.lib を C:\Program Files\Borland\BDS\4.0\Lib\ に上書きコピーする。
- 同じく cc3270*.dll を C:\WINDOWS\SYSTEM32\ に上書きコピーする。
これで問題のプロジェクトをビルドし直すと、何回実行しても落ちなくなりました。
QualityCentral のバグ報告にも追記しましたので、しっかり検証された上で次回の Update に取り込まれることを祈っています。
みなさま本当にありがとうございました!
(すみません、文意が不明瞭でしたので書き直しました)
> ken さん
情報ありがとうございます。
VC6 や Borland コンパイラでの不具合対応とかが
入っているようですね…。
> Kaz さん
なななんですとー…。
もしよろしければ情報源を教えて頂けると嬉しいです。
もっとも、手元の C++ 規格書(*1)を "thread" で検索してみた所、
1 箇所しか出てこない上に、スレッドセーフに関する記述はなさそう…
という所までは先ほど確認しました。
規格書にないから対応不要、というのも一応筋は通っていると
思いますが、慣れ親しんだ iostream 等のライブラリを
マルチスレッド環境で使えないのはやはり不便に感じます…。
このスレの17番の記事でも書きましたが、
Dinkumware 自体は マルチ/シングルスレッド両対応で
セットアップ時に設定可能なので、Borland が何らかの理由(*2)で
意図的に OFF 設定 にしているのかも知れませんね。
それならそうで QC (#31765)の Status をさっさと
As designed(そういうもんでっせ)にしてくれたら
あきらめもつくのに…なんて思います(^^;)。
もっとも、せっかくの Dinkumware なのに勿体ないと思いますが。
STLport の方は特徴の一つとしてスレッドセーフを謡ってます
ので、そろそろ移行を考えようかと思います…。
(*1)
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+14882%2D2003
で購入した PDF ファイルのやつです
(*2)
マルチスレッド実行にも何の問題もなかった
VC++ は C++/C いずれのライブラリにも Dinkumware を使っており
BDS は Cランタイムのみ独自のもの済ませているあたりが気になります。
> ken さん
情報ありがとうございます。
VC6 や Borland コンパイラでの不具合対応とかが
入っているようですね…。
> Kaz さん
なななんですとー…。
もしよろしければ情報源を教えて頂けると嬉しいです。
もっとも、手元の C++ 規格書(*1)を "thread" で検索してみた所、
1 箇所しか出てこない上に、スレッドセーフに関する記述はなさそう…
という所までは先ほど確認しました。
規格書にないから対応不要、というのも一応筋は通っていると
思いますが、慣れ親しんだ iostream 等のライブラリを
マルチスレッド環境で使えないのはやはり不便に感じます…。
このスレの17番の記事でも書きましたが、
Dinkumware 自体は マルチ/シングルスレッド両対応で
セットアップ時に設定可能なので、Borland が何らかの理由(*2)で
意図的に OFF 設定 にしているのかも知れませんね。
それならそうで QC (#31765)の Status をさっさと
As designed(そういうもんでっせ)にしてくれたら
あきらめもつくのに…なんて思います(^^;)。
もっとも、せっかくの Dinkumware なのに勿体ないと思いますが。
STLport の方は特徴の一つとしてスレッドセーフを謡ってます
ので、そろそろ移行を考えようかと思います…。
(*1)
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+14882%2D2003
で購入した PDF ファイルのやつです
(*2)
マルチスレッド実行にも何の問題もなかった
VC++ は C++/C いずれのライブラリにも Dinkumware を使っており
BDS は Cランタイムのみ独自のもの済ませているあたりが気になります。
シングルスレッド・マルチスレッドどちらの標準ライブラリを
使うのか、アプリ開発者の選択に任せるという方針は
全く正しいと思います。
VC++ もコード生成のオプションでリンクされるランタイムが
切り替わりますし…。(*1)
ただ、BDS はプロジェクト作成の時に「マルチスレッド」なる
チェックボックスがあり、チェックを入れるとリンクされる
ランタイムがマルチスレッド対応の cw32mt/cw32mt.lib に
なるにも関わらす、iostream 系は依然非対応…というのは
整合性が取れてないと思うのです…。
#31765 の Status が Opened のままなのは、
きっとそのうち対応しようとしてくれている…と
信じて待ちたいと思います。
(*1) 最も、VisualStudio2005 からはマルチスレッドのみに
なってしまいましたが…。
使うのか、アプリ開発者の選択に任せるという方針は
全く正しいと思います。
VC++ もコード生成のオプションでリンクされるランタイムが
切り替わりますし…。(*1)
ただ、BDS はプロジェクト作成の時に「マルチスレッド」なる
チェックボックスがあり、チェックを入れるとリンクされる
ランタイムがマルチスレッド対応の cw32mt/cw32mt.lib に
なるにも関わらす、iostream 系は依然非対応…というのは
整合性が取れてないと思うのです…。
#31765 の Status が Opened のままなのは、
きっとそのうち対応しようとしてくれている…と
信じて待ちたいと思います。
(*1) 最も、VisualStudio2005 からはマルチスレッドのみに
なってしまいましたが…。
> Atomic operations on these objects, such as extractions and insertions, are protected against simultaneous access from different threads. (中略) Thus, you can safely share iostream objects across threads without worrying about loss of integrity.
ということなので、別々のスレッドから同時にアクセスしても保護されるということですよね。
> If you want changes to the file to be reflected after each atomic write, you must change the definition of the macro _IOSTREAM_OP_LOCKS from 0 to 1 (後略)
iostreamでの書き込みが即座にファイルに反映されるようにするには_IOSTREAM_OP_LOCKSを0から1に変えろと書いてますので、これが競合回避のためのものとは思えません。
マルチスレッド対応かどうかは別のマクロMT/NO_MTで切り替えてますし。
ということなので、別々のスレッドから同時にアクセスしても保護されるということですよね。
> If you want changes to the file to be reflected after each atomic write, you must change the definition of the macro _IOSTREAM_OP_LOCKS from 0 to 1 (後略)
iostreamでの書き込みが即座にファイルに反映されるようにするには_IOSTREAM_OP_LOCKSを0から1に変えろと書いてますので、これが競合回避のためのものとは思えません。
マルチスレッド対応かどうかは別のマクロMT/NO_MTで切り替えてますし。
なんか以下の部分が怪しそうですね。_MSC_VERが定義されている場合はout-of-lineの関数を使うのに対して、Borlandでは当然このマクロを定義しないので、/* non-Windows multithreading */のほうを使ってしまいます。_MAYBE_LOCKの定義を見れば、ロケールのロックがかからないのは明らかなので、ロケール関係がロックなしで使われてしまうことになります。
#elif defined(_WIN32_WCE) || defined(_MSC_VER)
#define _LOCKIT(x) lockit x
explicit _Lockit(); // set default lock
explicit _Lockit(int); // set the lock
~_Lockit(); // clear the lock
private:
int _Locktype;
#else /* non-Windows multithreading */
#define _LOCKIT(x) lockit x
explicit _Lockit()
: _Locktype(_LOCK_MALLOC)
{ // set default lock
_MAYBE_LOCK
_Locksyslock(_Locktype);
}
explicit _Lockit(int _Type)
: _Locktype(_Type)
{ // set the lock
_MAYBE_LOCK
_Locksyslock(_Locktype);
}
~_Lockit()
{ // clear the lock
_MAYBE_LOCK
_Unlocksyslock(_Locktype);
}
private:
int _Locktype;
#endif /* _MULTI_THREAD */
#elif defined(_WIN32_WCE) || defined(_MSC_VER)
#define _LOCKIT(x) lockit x
explicit _Lockit(); // set default lock
explicit _Lockit(int); // set the lock
~_Lockit(); // clear the lock
private:
int _Locktype;
#else /* non-Windows multithreading */
#define _LOCKIT(x) lockit x
explicit _Lockit()
: _Locktype(_LOCK_MALLOC)
{ // set default lock
_MAYBE_LOCK
_Locksyslock(_Locktype);
}
explicit _Lockit(int _Type)
: _Locktype(_Type)
{ // set the lock
_MAYBE_LOCK
_Locksyslock(_Locktype);
}
~_Lockit()
{ // clear the lock
_MAYBE_LOCK
_Unlocksyslock(_Locktype);
}
private:
int _Locktype;
#endif /* _MULTI_THREAD */
調査ありがとうございます。(_o_)
前回調べた時に なぜ _IOSTREAM_OP_LOCKS に行きついたかどうかを思い返していました。
以下は 全て C:\Program Files\Borland\BDS\4.0\include\dinkumware\yval.h からの引用です。
−−−ここから−−−ここから−−−ここから−−−
class _CRTIMP2 _Mutex
{ // lock under program control
public:
#if !_MULTI_THREAD || !_IOSTREAM_OP_LOCKS
void _Lock()
{ // do nothing
}
void _Unlock()
{ // do nothing
}
#else /* !_MULTI_THREAD || !_IOSTREAM_OP_LOCKS */
_Mutex();
~_Mutex();
void _Lock();
void _Unlock();
private:
_Mutex(const _Mutex&); // not defined
_Mutex& operator=(const _Mutex&); // not defined
void *_Mtx;
#endif /* !_MULTI_THREAD || !_IOSTREAM_OP_LOCKS */
};
} // extern "C++"
−−−ここまで−−−ここまで−−−ここまで−−−
こちらも、_MULTI_THREAD と _IOSTREAM_OP_LOCKS の両方が 1 に
定義されていないと、この Mutex の _Lock()/_Unlock() の中身が
空になってしまいます。
_MULTI_THREAD は、yval.h の内部で以下の手順で 1 に定義されるので問題ありません。
- コンパイルオプションに -tWM を指定されていると __MT__ が定義される
- __MT__ が定義されていると _NO_MT は無変更(されてなければ 1 になる)
- _NO_MT が 1 でなければ _MULTI_THREAD を 1 に定義
また、yval.h の冒頭には
#define _IOSTREAM_OP_LOCKS 0 /* 0 for no iostream locks, 1 for atomic */
とあるのですが、Dinkumware のドキュメントと微妙に意味が違うような気がするのは気のせいでしょうか…。
前回調べた時に なぜ _IOSTREAM_OP_LOCKS に行きついたかどうかを思い返していました。
以下は 全て C:\Program Files\Borland\BDS\4.0\include\dinkumware\yval.h からの引用です。
−−−ここから−−−ここから−−−ここから−−−
class _CRTIMP2 _Mutex
{ // lock under program control
public:
#if !_MULTI_THREAD || !_IOSTREAM_OP_LOCKS
void _Lock()
{ // do nothing
}
void _Unlock()
{ // do nothing
}
#else /* !_MULTI_THREAD || !_IOSTREAM_OP_LOCKS */
_Mutex();
~_Mutex();
void _Lock();
void _Unlock();
private:
_Mutex(const _Mutex&); // not defined
_Mutex& operator=(const _Mutex&); // not defined
void *_Mtx;
#endif /* !_MULTI_THREAD || !_IOSTREAM_OP_LOCKS */
};
} // extern "C++"
−−−ここまで−−−ここまで−−−ここまで−−−
こちらも、_MULTI_THREAD と _IOSTREAM_OP_LOCKS の両方が 1 に
定義されていないと、この Mutex の _Lock()/_Unlock() の中身が
空になってしまいます。
_MULTI_THREAD は、yval.h の内部で以下の手順で 1 に定義されるので問題ありません。
- コンパイルオプションに -tWM を指定されていると __MT__ が定義される
- __MT__ が定義されていると _NO_MT は無変更(されてなければ 1 になる)
- _NO_MT が 1 でなければ _MULTI_THREAD を 1 に定義
また、yval.h の冒頭には
#define _IOSTREAM_OP_LOCKS 0 /* 0 for no iostream locks, 1 for atomic */
とあるのですが、Dinkumware のドキュメントと微妙に意味が違うような気がするのは気のせいでしょうか…。
検索してみたら、_Mutex は C:\Program Files\Borland\BDS\4.0\include\dinkumware\streambuf で使われているようです。
_LOCK_LOCALE は確かに有効そうですね。帰宅したら試してみたいと思います。
> ていうか、non-Windows multithreadingってLinuxのことなんですかね?
どうもそんな気がしています。
今回の件とは多少話が反れますが、C:\Program Files\Borland\BDS\4.0\include\dinkumware\xlocinfo の一行目をみる限り、どうも Linux 用のヘッダを流用しているようなのです…。
別件のバグ(QC# 32177)を追いかけていた時に見つけたのですが、実装内容も含めて脱力してしまいました…。
(当時の様子: http://d.hatena.ne.jp/logion/20060806#p1)
_LOCK_LOCALE は確かに有効そうですね。帰宅したら試してみたいと思います。
> ていうか、non-Windows multithreadingってLinuxのことなんですかね?
どうもそんな気がしています。
今回の件とは多少話が反れますが、C:\Program Files\Borland\BDS\4.0\include\dinkumware\xlocinfo の一行目をみる限り、どうも Linux 用のヘッダを流用しているようなのです…。
別件のバグ(QC# 32177)を追いかけていた時に見つけたのですが、実装内容も含めて脱力してしまいました…。
(当時の様子: http://d.hatena.ne.jp/logion/20060806#p1)
yval.h の _MAYBE_LOCK のマクロを以下のように変更して試してみました。(このマクロは C++ランタイムソースでは使われていないので、C++ランタイムの再ビルドはしていません)
・変更前−−−−
#define _MAYBE_LOCK \
if (_Locktype == _LOCK_MALLOC || _Locktype == _LOCK_DEBUG)
・変更後−−−−
#define _MAYBE_LOCK \
if (_Locktype == _LOCK_MALLOC || _Locktype == _LOCK_DEBUG || _Locktype == _LOCK_LOCALE)
結果は、10回中 5回の割合で落ちるようです…。orz
・変更前−−−−
#define _MAYBE_LOCK \
if (_Locktype == _LOCK_MALLOC || _Locktype == _LOCK_DEBUG)
・変更後−−−−
#define _MAYBE_LOCK \
if (_Locktype == _LOCK_MALLOC || _Locktype == _LOCK_DEBUG || _Locktype == _LOCK_LOCALE)
結果は、10回中 5回の割合で落ちるようです…。orz
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
C++ Builder 更新情報
-
最新のイベント
-
最新のアンケート
-
まだ何もありません
-
C++ Builderのメンバーはこんなコミュニティにも参加しています
人気コミュニティランキング
- 1位
- お洒落な女の子が好き
- 90040人
- 2位
- 大人のmixi【おとミク】
- 6419人
- 3位
- 独り言
- 9045人