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: Re: mutex and mailbox query


On Sun, 21 Sep 2003, Hans Dermot Doran wrote:

> The destruction of an owner locked mutex is not documented and actually
> stopping the scheduler appears to me to be a little drastic for such a
> piddly operation and could be, if one where were so inclined, interpreted as
> a design flaw.

Actually the scheduler is stopped (locked) internally while you call
cyg_mutex_lock/unlock/trylock etc... thats the case with many
system calls. It is needed to mantain the consistency of internal
structures. Imagine what would happen if thread 1 calls
cyg_mutex_lock(mx) and gets preempted inside it by thread 2 which also
calls cyg_mutex_lock(mx).

In you case - when you call cyg_mutex_lock(mx) ... cyg_mutex_release(mx)
and before you could do anything else you can get preempted by another thread
which calls cyg_mutex_lock(mx). So when the first thread gets the CPU back
there are still threads waiting on mx, calling cyg_mutex_destroy(mx) now
is not a good idea. Thats why the scheduler lock.

Also the owned mutex should not be destroyed - thats because
it is not ment to be destroyed if locked. Other things may depend
on it - and they do - look in kernel/current/src/sync/mutex.cxx -
there is the priority inversion thing. And you don't know what changes
the new versions will bring.

savin


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


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