This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: cyg_io_write
>>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
Bob> Make sure you never lock an already locked mutex. I remember
Bob> spending quite some time searching for a deadlock caused by
Bob> this .... (I am not sure it will happen in your case though)
Bob> Might be an idea do modify the cyg_mutex_t behaviour in such
Bob> a way that a call to cyg_mutexc_lock doesnt do anything if it
Bob> is called from the thread that already owns the lock. Similar
Bob> to what "How are they called again ??" does with their
Bob> CRITICAL_SECTION objects. Cygnus folks ??
Some systems provide recursive mutexes, where a thread can lock a
given mutex multiple times. They involve some additional overhead, in
that you have to keep track of how many times the current thread has
locked the mutex.
Also, some people (including myself) consider the concept of recursive
mutexes to be fundamentally flawed. One way of looking at mutexes is
that they guarantee an invariant condition for some shared resource:
whenever a thread has claimed a mutex that thread will have some
guarantees about the current state; when the thread releases the mutex
it must provide a guarantee that the invariant is preserved. If this
thread does not even know whether or not it already owns the mutex,
how it can possibly provide any guarantees about the state of the
shared resource?
eCos will raise an assertion failure when an attempt is made to lock a
mutex recursively. Enabling assertions in the system when developing
application code is recommended, unless you are very low on memory in
the development system.
Bart Veer // eCos net maintainer