'pthread_mutex_unlock() BUG in libc_r?

[Daniel Eischen]

On Mon, 16 Mar 2009, Norbert Koch wrote:

> Hello,
>
> first of all, I know that libc_r is an ancient and
> no more supported library.
> But what I found looks like such a huge bug that
> I would like to hear a different opinion about
> that. Because, may be I am totally wrong with that.
> (Btw. I am doing this under FreeBSD 4.11 but libc_r
> looks the same under 7.1)
>
> I am having two threads A (low priority) and B (high priority).
> This is the pseudo code:
>
> Thread A:
>  forever {
>    sleep_some_time()
>    call common_func()
>    set global ponter P to NULL
>  }
>
> Thread B:
>  forever {
>    sleep_some_time()
>    set global pointer P to not NULL
>    call common_func()
>    assert P is not NULL
>  }
>
> common_func()
> {
>  pthread_lock_mutex(M)
>  do something completely_unrelated
>  pthread_mutex_unlock(M)
> }

There is no guarantee that pthread_mutex_unlock() (or
other unlocks of synchronization types) are preemption
points.

Also, you cannot assume that the run time for each
thread is the same.  The threads are started at
separate times, and there may even be a scheduling
preemption point between the two successful calls
to pthread_create() causing one thread to start
before the next thread is created.  There is no
guarantee that sleep_some_time() ends exactly the
same for both threads.

In order for this to work, you need both threads
A and B to block on a synchronization variable
(mutex, CV, etc) and to have the main thread (or
another thread) wake them up after ensuring that
they both are waiting.

-- 
DE