This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Re: mutex and mailbox query
- From: Savin Zlobec <savin at torina dot fe dot uni-lj dot si>
- To: Hans Dermot Doran <hans dot doran at ibhdoran dot com>
- Cc: <ecos-discuss at sources dot redhat dot com>
- Date: Sun, 21 Sep 2003 15:20:31 +0200 (CEST)
- Subject: RE: [ECOS] 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