Re: [gtkmm] threadsystem

[Paul Davis <paul linuxaudiosystems com>]

>does anyone know why glib2 does not have semaphores? what do you think to incl

because pthreads do not include semaphores as you are trying to define them.

>ude it in gtkmm anyway (based on pthread as glib)?
>the problem with the existing possibilities (mutexes and conditions) is that e
>.g. if a condition is signalled before another thread waits for the condition 
>the other thread doesn't know that the condition has already been signaled.

doing this is a basic and absolutely fundamental error in thread programming.
you just cannot do this. conditions are always used like this:

to signal:

    pthread_mutex_lock (&mutex_that_guards_condition);
    pthread_condition_signal (&condition);
    pthread_mutex_unlock (&mutex_that_guards_condition);

to receive:

    pthread_mutex_lock (&mutex_that_guards_condition);
    pthread_condition_wait (&condition, &mutex_that_guards_condition);
    pthread_mutex_unlock (&mutex_that_guards_condition);

not using the mutex will nearly always result in missed condition signals.

>another problem is that a condition doesn't know anything about how often it h
>as been signaled.

that follows from your lack of use of a mutex, but is also partly a
result of the semantics of P.1003 condition variables. 

>i need exactly these behaviours in an application. trying to implement a semapho
>re with mutexes and conditions is impossible in my opinion because one can never
>mutex the variables like it is needed (i tried it already). additionally it is 
>much more effort than to write a semaphore class based on pthread.

this is simply not true. go get a good book on thread program and read
it several times.


--p