hi
so, i'm doing this:

//thread 1:
al_lock_mutex(job);
al_start_thread(thread2); 
for(/*some condition*/){
  al_wait_cond(sig,job); 
}

//thread 2:
while(1){
  al_lock_mutex(job); 
  /* work... */
  al_signal_cond(sig);
  al_unlock_mutex(job);
}

i've read the pthreads docs and googled for quite a few hours now. as far as i understand:
-thread1 gets the mutex, thread2 starts and waits.
-when i call wait_cond, thread1 starts waiting and unlocks the mutex, so thread2 can do some work. this apparently is atomic.
-now, thread2 signals and unlocks. when these 2 conditions are met, the wait in thread1 wakes up and gets back the mutex. this last step done by wait_cond should be atomic as well, but apparently is not.

what happens is that thread2 gets the mutex "while" thread1 is waking up.

if i add a small al_rest delay after the wait_cond, i get this behavior 100% of the time. if i add this delay after thread2 unlocks, thread1 gets the mutex first and works like i want it to :p

where am i being stupid?

The problem is that thread2 sometimes acquires the mutex before thread1 acquires the mutex. You can picture thread2 like this:

//thread2
al_lock_mutex(job); 
/* work... */
al_signal_cond(sig);
al_unlock_mutex(job);
al_lock_mutex(job); 
/* work... */
al_signal_cond(sig);
al_unlock_mutex(job);
...

As you can see, thread2 unlocks the mutex and then immediately locks it. If you put
al_rest after al_unlock_mutex, like this:

//thread2
al_lock_mutex(job); 
/* work... */
al_signal_cond(sig);
al_unlock_mutex(job);
al_rest(1);
al_lock_mutex(job); 
/* work... */
al_signal_cond(sig);
al_unlock_mutex(job);
al_rest(1);
...

then your code works because thread1 is given a chance to do its work.

In order to achieve what you want, you need a semaphore: the worker thread increments the semaphore, and the waiting thread decrements the semaphore or waits for the semaphore to be incremented.

There is no guarantee that the thread that is woken up by al_signal_cond will run immediately. What happens under the hood is that the operating system puts the thread in a queue for execution. In the mean time, the other thread gets another execution slot from the operating system, and locks the mutex.

You need a semaphore.

thanks for the replies
exactly as some of you suggested, i was expecting the wait_cond to get back the mutex atomically.