sem_getvalue()は成功するのにsem_wait()で失敗します

Question

スレッドの初期化処理完了を待つため、
sem_wait(&thread_inf[cnt].sem)を使っているのですが、
実行結果が失敗になります。(strerror(errno)の結果は[Invalid argument]になります)
確認のため、直前で
sem_getvalue(&thread_inf[cnt].sem, &val)を実行すると、
こちらは成功します。
(遅れて実行されるスレッド側のsem_post(&thread_inf[cnt].sem)も返り値は成功になります)

このthread_infはグローバル変数として宣言して使用しているのですが、
どこかまずいところがあるのでしょうか?

原因・対応がわかりましたら、回答お願いいたします。

Answer 1

それぞれのthread_inf[cnt].semに対して、sem_initもしくはsem_openをする必要があるのではないでしょうか。

sem_initでの例を書いてみました。

（GCC 4.8.3 Cygwinを使用）

#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <pthread.h>
#include <semaphore.h>

sem_t sem;

void *thread_f();

int main()
{
  pthread_t th;
  int shared;
  unsigned int value;
  int r;

  shared = 1;
  value = 0;

  r = sem_init(&sem, shared, value);
  printf("r=%d, err=%s\n", r, strerror(errno));

  r = sem_getvalue(&sem, &value);
  printf("r=%d, err=%s\n", r, strerror(errno));

  if (pthread_create(&th, NULL, thread_f, (void *)NULL))
  {
    printf("スレッドの生成に失敗\n");
    return 1;
  }

  printf("sem_wait\n");
  r = sem_wait(&sem);
  printf("r=%d, err=%s\n", r, strerror(errno));

  return 0;
}

void *thread_f() {
  sleep(5);
  printf("sem_post\n");
  sem_post(&sem);
  return (void *)NULL;
}

Comments

[kutsulog]

すみません
書き漏れていましたが、それぞれのthread_inf[cnt].semは
sem_init( &thread_inf[cnt].sem, 0, 0 )で初期化しております。
このときの返値は
ret:0/strerror(errno):Successになります。

sem_init( &thread_inf[cnt].sem, 1, 0 )も試してみましたが、
結果は変わらずでした。

[argius]

そうですか...
上記のコードはこちらでは正しく動作しましたので、これとほぼ同じコードなのでしたら、プログラミング以外の問題の可能性もあるかも知れません。

本物のコードを提示するのは難しいと思いますので、もし、再現する最小限のコードを提示していただければ、コードが問題なのか、環境依存の問題なのかを切り分けられる可能性はあります。

[kutsulog]

thread_infに使っている構造体の中身が
typedef struct tagHOGE
{
BOOL a_flg;//Windowsから移植の都合でtypedef int BOOLしています
BOOL b_flg;//Windowsから移植の都合でtypedef int BOOLしています
//自作DBアクセスクラスです
dbAccess *pDB;
DWORD thread_no;//Windowsからの移植の都合でtypedef uint32_t DWORDしています
char logfile[80+1];
pthread_t id; //各スレッドのid
pthread_mutex_t mutex; // スレッド内調整用
sem_t sem1; // スレッド->メイン用
sem_t sem2; // メイン->スレッド用
}HOGE, *PHOGE;
の構成だったのですが、
sem_t sem1とsemt_sem2をいちばん上に持って行ったところ
sem_waitがret:0/strerror(errno):Successになりました。

他のメンバーの操作時にメモリ破壊をしているのかと、
sem1,sem2の位置を戻して他のメンバに対する処理をコメントアウトしたのですが、
この場合はret:-1/strerror(errno):Invalid argumentでした。

コメントアウト対象
(sem_init前)
sprintf(thread_inf[cnt].logfile, "./TESTED_MODULE.LOG");//<-文字列そのままです
(sem_init後)
thread_inf[cnt].b_flg = DISABLE; /*#define DISABLE 0*/
pthread_mutex_init( &thread_inf[cnt].mutex, NULL );
thread_inf[cnt].thread_no = cnt + 1;
thread_inf[cnt].pDB = new dbAccess;
thread_inf[cnt].b_flg = ENABLE; /*#define ENABLE 1*/
(thread_inf[cnt].a_flgは今動かしている範囲では操作していません)

一応動くには動きましたが、どっかにしわ寄せが出そうで。。。

[argius]

thread_inf自体はどのように宣言、初期化していますか？
配列サイズは固定ですか？

[argius]

構造体の中が壊れていて、順番を変えたら発現しなくなったというのは、thread_infのアロケートに問題があるのかも知れません。
Windowsからに限らず、移植前はたまたま動いていたのが新しいOSに移植したら問題が顕在化したというケースはよくあります。

[kutsulog]

thread_infの宣言は
HOGE thread_inf[THREAD_MAX_SIZE]で宣言しています。
(reallocなどはしておらず、THREAD_MAX_SIZEは今のところ1です)

初期化は最初にmemset( &thread_inf[cnt], 0x00, sizeof(HOGE))した後
それぞれの値を設定して使っています。

セマフォ変数はもともとWindows時代は
EventのPOST,WAITしていたところの代替で
今回の移植から使っています。

[argius]

そうですか...他に考えられるとしたら、BlueMoonさんもおっしゃっていますが、セマフォ―関数とは無関係の何かしらの破壊的操作があるのでは？、くらいでしょうか。
地道にすべてのthread_infの操作前後で状態を見ていくしか思いつきません。
お役にたてずにすみません。

Answer 2

thread_inf[cnt].semの値をログ出力などして、sem_init実行直後とsem_wait実行時で比較してみてはどうでしょうか。配列添え字のcntの値も気になります。

不要な説明かも知れませんがセマフォについてです。sem_はそのライブラリ関数になります。スレッドは並列実行されるので共通資源へのアクセス（共通の初期化処理、スレッド共通の変数へのアクセス等）に排他制御が必要になるのかと思います。

Comments

[kutsulog]

init/wait/post
それぞれの前(initは後)で値とアドレスをprintfして確認しましたが、
問題はありませんでした。
添字cntはforでそれぞれ初期化するために使っていますが、
for( int cnt = 0; cnt < 1; cnt++ )でも失敗しました。

[BlueMoon]

別回答のコメントを見ますところ、構造体内のsem_tの位置を変えて成功したということであれば、構造体の他メンバを使用している処理が領域破壊している可能性が高いと思います。
思いつく調査方法は、関係処理をコメントアウトするなどして被疑部分を絞りこんでみる等です。