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]

Re: No binary semaphore in C API?


>From: Sergei Organov <osv@javad.ru>
>To: bartv@redhat.com
>CC: ecos-discuss@sourceware.cygnus.com
>Subject: Re: [ECOS] No binary semaphore in C API?
>Date: 30 Mar 2001 14:22:43 +0400
>

>I think that original post has a scenario for which there is no primitive 
>in
>eCos that exactly matches requirements and there will never be one I guess 
>as
>the problem that should be solved is rather complex and hopefully
>rare. Somebody (you?) described it as "mutual exclusion between thread
>groups". For me it belongs to the same class as read-write locks but
>apparently is even more complicated. One of solutions, IMHO, is to 
>implement
>special object on top of primitives that eCos provides and use it in the
>application. Then it will be this object that will take care of preserving
>semantics of eCos primitives it uses. And if it is possible to build it on 
>top
>of current binary semaphore, it is also possible to build it on top of 
>current
>counting semaphore, I believe.
>
>I'm still not convinced that tuning eCos primitive for such questionable 
>usage
>is a good idea especially as it prohibits another possible application.
>


I believe that the primitive(s) that Sergei was talking about
is more in line with the semantic of the WIN32/OS/2 "Event"
primitives. Something that has a semantic of a switch ( on/off ).

This semaphore, called from now "EventX", has two states,

  + Reseted, Posted.

Once reseted, any thread "waiting" on that semaphore will block. Once,
the semaphore is "posted", all threads are unblocked, and it remains on that 
state until it is explicited put back on the "Reseted" state.

Interface:

  class EventX
  {
    public:

    void post();
    bool wait( some timeout here );
    void reset();
  };

As he mentioned on the first message, this type of primitive
is very handy, because you do not need a "thread id" of the
receiving thread to be used. I have used the "Binary"
semaphores to archieve this semantic in some cases,
but they never matches 100%.

Rosimildo.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com


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