Opened 11 years ago

Closed 11 years ago

#2990 closed bug (fixed)

Not POSIX-conformant behaviour of pthread's mutexes

Reported by: daste Owned by: axeld
Priority: normal Milestone: R1
Component: System/ Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


I was trying to port some of my own stuff to Haiku, but enocuntered the following non standard behaviour in your pthread implementation (using PTHREAD_MUTEX_ERRORCHECK mutexes):

  • trying to unlock a mutex before locking it causes an erroneous "mutex unlocked from foreign thread!" error message to be printed on screen and pthread_mutex_lock() returns 0 instead of EPERM;
  • trying to lock a mutex for the second time in the same thread, pthread_mutex_lock() returns EBUSY instead of EDEADLK;
  • EBUSY often returned by pthread_mutex_lock(), which is plain weird. pthread_mutex_lock() should just "block the thread" and cannot return EBUSY (that return value is valid only for pthread_mutex_trylock()).

Change History (4)

comment:1 Changed 11 years ago by scottmc

daste, can you post a simple test case program for each of these? That may help speed up fixing this.

comment:2 Changed 11 years ago by bonefish

Resolution: fixed
Status: newclosed

The first two items are fixed in hrev28354. The third I could not see in the code. EBUSY was only returned instead of EDEADLK.

comment:3 Changed 11 years ago by daste

Resolution: fixed
Status: closedreopened

Just did the tests again, the third problem persists. It returns EDEADLK now, I think because the mutex's owner is not changed in pthread_mutex_unlock(), as far as I can tell from looking at libroot's source code (I can't manage to compile it as of now).

It seems like mutex's owner is only set to -1 for PTHREAD_MUTEX_RECURSIVE mutexes, which, according to my understanding, is wrong.

comment:4 Changed 11 years ago by bonefish

Resolution: fixed
Status: reopenedclosed

Thanks, fixed in hrev28428.

Note: See TracTickets for help on using tickets.