Re: [ECOS] cyg_io_write

[Bart Veer <bartv at redhat dot com>]

>>>>> "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