[ECOS] pthread_mutex_unlock when mutex is not locked
Wed Apr 27 11:51:00 GMT 2005
Rubén Pérez de Aranda Alonso <firstname.lastname@example.org> writes:
> 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."
> So, I think the unlock method must return an error code. In eCOS, this
> method returns void. If we check the mutex is locked at least we avoided the
> crash of the system.
eCos doesn't currently support recursive mutexes -- partly because
some of us consider them the work of the devil and partly because it
would require some significant work on the kernel mutex code to make
it work smoothly with the priority inversion protocols.
DSRs are not threads, and can be called in the context of any thread
in the system. Calling mutex unlock from a DSR would do it in the
context of the thread that happened to running when the interrupt
occured. If you are lucky, this will be the thread that locked the
mutex and it will work. If you are unlucky, it will be a different
thread and the mutex will not get unlocked.
Condition variables can be signalled from DSRs and you should really
use one of those to wake up any threads.
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss