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


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


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