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: "Hans Dermot Doran" <hans dot doran at ibhdoran dot com>
- To: "Savin Zlobec" <savin at torina dot fe dot uni-lj dot si>, "Andrew Lunn" <andrew at lunn dot ch>
- Cc: <ecos-discuss at sources dot redhat dot com>
- Date: Sun, 21 Sep 2003 12:35:57 +0200
- Subject: RE: [ECOS] Re: mutex and mailbox query
- Reply-to: <hans dot doran at ibhdoran dot com>
Thanks for the replies
the cyg_mutex_release function releases the mutex returning null to all
those threads waiting on the mutex, without affecting the owner, therefore
there should be no reason to involve the cyg_thread_release function. The
question is whether the kernel is robust enough to handle a get operation on
a mutex which doesn't exist.
However, it does not appear to be documented what happens if you delete a
mailbox on which a thread is blocked. In my case, since I am only
synchronising two known and named threads, a cyg_thread_release operation
should work (previously calling cyg_mailbox_waiting_to_get with the name of
the other thread). But its is not very elegant and defeats the generic
purpose of a mailbox.
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.
Regards
Hans
-----Original Message-----
From: Savin Zlobec [mailto:savin@torina.fe.uni-lj.si]
Sent: Samstag, 20. September 2003 23:47
To: Andrew Lunn
Cc: hans.doran@ibhdoran.com; ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Re: mutex and mailbox query
On Sat, 20 Sep 2003, Andrew Lunn wrote:
> > > Problem is, you have no way of knowing if any threads are waiting on
> > > the mbox or the mutex. There are no API calls to tell you this.
> >
> > Yes, the following scenario limits the usage of mbox to cyg_mbox_tryget,
> > or maybe the cyg_thread_release could be used.
>
> Don't forget that cyg_mbox_put will also block, so you also have to do
> a tryput.
I just looked from one side :-)
> cyg_thread_release is no use, you don't know which threads to
> release!
There should be some aditional logic in the application to use
cyg_thread_release. Maybe it would be better to use a conditional
variable and implement the messaging based on it. That way some
aditional info about the message queue could be passed between
threads.
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