This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_mutex_unlock when mutex is not locked


On Wed, Apr 27, 2005 at 11:21:20AM +0200, Rub??n P??rez de Aranda Alonso wrote:
> I think the mutex is appropiate for the explained scenario.
> 
> The standard says:
> "If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex maintains 
> the concept of a lock count. When a thread successfully acquires a mutex 
> for the first time, the lock count is set to one. Every time a thread 
> relocks this mutex, the lock count is incremented by one. Each time the 
> thread unlocks the mutex, the lock count is decremented by one. When the 
> lock count reaches zero, the mutex becomes available for other threads 
> to acquire. If a thread attempts to unlock a mutex that it has not 
> locked or a mutex which is unlocked, an error will be returned."

And the next paragraph says:

If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively
lock the mutex results in undefined behaviour. Attempting to unlock
the mutex if it was not locked by the calling thread results in
undefined behaviour. Attempting to unlock the mutex if it is not
locked results in undefined behaviour.

Have you configured the mutex to be PTHREAD_MUTEX_RECURSIVE?  I guess
not. I would call a crash an undefined behavour, so i think its OK
according to the second paragraph.

Also, a DSR is not a thread. The paragraph you quoted always talks
about threads.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]