'pthread_mutex_unlock() BUG in libc_r?

Norbert Koch nkoch at demig.de
Mon Mar 16 01:46:10 PDT 2009


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)
}

Without calling common_func() all is ok.
With common_func the assertion fails from
time to time.

The problem I found is in pthread_mutex_unlock().
As far as I understand the code, the next thread
waiting on the mutex is made runnable, but there
is no call of the scheduler! This means, that the
lower priority thread will continue running until
blocking itself or being switched away by running
out of time.
I see the same (wrong?) code in pthread_cond_signal()
and pthread_cond_broadcast().

So, could anyone please enlighten me if I am totally
wrong here or if there is perhaps some weird hidden
aspect in the posix standard I missed?

If I found a bug here, what about libthr/libpthread?
Are they behaving correctly?


Best regards,

Norbert Koch



More information about the freebsd-threads mailing list