pthread_cond_broadcast()

pthread_cond_broadcast()

[Lorin Hochstein]

Hi,

I'm somewhat new to pthreads programming, and especially new to the
win32 stuff. I'm trying to port some code from Linux to Windows NT, and
it seems to hang in the following case.

ThreadA {
 while(1) {
  pthread_cond_wait(cond, ...);
  /* do stuff */
 }
}

ThreadB {
  while(1) {
    pthread_cond_broadcast(cond, ...);
    /* do other stuff */
  }
}

The problem arises when there are are two instances of ThreadA (let's
call them A1 and A2), and one instances of thread B (call it B). When B
broadcasts a signal, A1 and A2 each wake up, respond to the signal, and
then go back to waiting. But B never gets switched back in after A1 and
A2 wait on the signal for the second time! 

I tried to test this by writing a smaller program which just does this
(attached to this e-mail). However, this smaller program seems to have
even bigger problems, the threads never respond to the broadcast, and I
have no clue why (it works just fine in Linux)! Could anybody offer any
assistance?

I am also attaching the makefile I used to compile the program (it
should work with both Microsoft's nmake utility, and the GNU make
utility, though I've been using nmake exclusively). (Note that the
include path and the library path are relative pathnames in the
makefile...)


Lorin Hochstein
thread_test.c
CC = cl.exe
LNK = link.exe
CFLAGS = /W3 /WX /MT /Z7
LIBS = pthread.lib
LIBPATH = /LIBPATH:..\pthreads
INC = /I..\pthreads
DEFINES = /D_WIN32_WINNT=0x400 /DSTDCALL=_stdcall

all: thread_test.obj
	$(LNK) /OUT:thread.exe $(LIBPATH) thread_test.obj $(LIBS)

thread_test.obj: thread_test.c
	$(CC) $(CFLAGS) $(DEFINES) $(INC) /c thread_test.c

Re: pthread_cond_broadcast()

[Peter Slacik]

Lorin Hochstein wrote:

> [....]
> I tried to test this by writing a smaller program which just does this
> (attached to this e-mail). However, this smaller program seems to have
> even bigger problems, the threads never respond to the broadcast, and I
> have no clue why (it works just fine in Linux)! Could anybody offer any
> assistance?

First, you are locking mutex1 in one thread - main(), and unlocks it in thread
which did not lock it - thread1(), thread2().

Second, you uses mutex1 for pthread_cond_wait() call (without locking it first).

Third, it is advisable to call pthread_cond_signal() / pthread_cond_broadcast()
with the associated mutex locked, and pthreads-win32 requests this.

And - each time check pthread_*() return values, even in the test code!

Hope this helps you

Peter Slacik

Re: pthread_cond_broadcast()

[Lorin Hochstein]

Thank you. Actually, the problem (in the original code, not in the test
code) was that the thread that called pthread_cond_broadcast() didn't
have the mutex... When I read the source code documentation for
pthread_cond_broadcast, I realized the error, and this fixed the
problem. You're supposed to do this with all pthread implementations
(not just pthreads-win32), but somehow Linux let me get away with it.

Lorin Hochstein

Peter Slacik wrote:
> 
> Lorin Hochstein wrote:
> 
> > [....]
> > I tried to test this by writing a smaller program which just does this
> > (attached to this e-mail). However, this smaller program seems to have
> > even bigger problems, the threads never respond to the broadcast, and I
> > have no clue why (it works just fine in Linux)! Could anybody offer any
> > assistance?
> 
> First, you are locking mutex1 in one thread - main(), and unlocks it in thread
> which did not lock it - thread1(), thread2().
> 
> Second, you uses mutex1 for pthread_cond_wait() call (without locking it first).
> 
> Third, it is advisable to call pthread_cond_signal() / pthread_cond_broadcast()
> with the associated mutex locked, and pthreads-win32 requests this.
> 
> And - each time check pthread_*() return values, even in the test code!
> 
> Hope this helps you
> 
> Peter Slacik