pthread地獄 part 2 (232ﾚｽ)
上
下
前
次
1-
新
61
(2)
: 2008/07/12(土)05:26
AA×
[
240
|
320
|480|
600
|
100%
|
JPG
|
べ
|
ﾚｽ栞
|
ﾚｽ消
]
61: [sage] 2008/07/12(土) 05:26:02 さらに、逆のパターンの実装は競合が発生するという主張について、 > clock_gettime(CLOCK_REALTIME, &now) > reltime = sleep_til_this_absolute_time -now; > cond_relative_timed_wait(c, m, &reltime); > If the thread is preempted between the first statement > and the last statement, the thread blocks for too long. Blocking, > however, is irrelevant if an absolute timeout is used. これもよく分からん。 このコードの間のプリエンプトが問題になるハードリアルタイムシステムなら リアルタイムOS使わないと無理じゃないの？ まあ、絶対時刻指定のAPIが要らないとまでは云わない。 > An absolute timeout also need not be > recomputed if it is used multiple times in a loop これもダメ、システム時刻の変更があり得る状況では、 システム時刻によって、ある時点から何秒経過したか知ることはできない。 タイムアウト内で、条件成立前にシグナルされる可能性がある場合、 俺の場合は、仕事ではWindowsなので、GetTickCount()を使い、 システム起動からの経過時間を元に次のタイムアウト指定値を求める。 Unixならプロセスの使用時間を取得できるAPIがあったはず。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/61
さらに逆のパターンの実装は競合が発生するという主張について これもよく分からん このコードの間のプリエンプトが問題になるハードリアルタイムシステムなら リアルタイム使わないと無理じゃないの？ まあ絶対時刻指定のが要らないとまでは云わない これもダメシステム時刻の変更があり得る状況では システム時刻によってある時点から何秒経過したか知ることはできない タイムアウト内で条件成立前にシグナルされる可能性がある場合 俺の場合は仕事ではなのでを使い システム起動からの経過時間を元に次のタイムアウト指定値を求める ならプロセスの使用時間を取得できるがあったはず
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 171 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
ぬこの手
ぬこTOP
0.046s
