Re: epicsEventSignal() question

["Johnson, Andrew N." <anj@aps.anl.gov>]

Hi Mike,

Have you worked out what those semFlush() calls are actually doing in the original code? Do they always come immediately after a semGive() for example? I think you would be best advised to try to discover what is actually going on in the original implementation instead of just trying to mechanically convert every call; my previous discussion was partly to explain that in reality the semFlush() probably wasn't doing what the original author might have thought, and as a result you might not need to replace it with anything. Once you've worked out how the various tasks communicate with each other you'll be in a better position to decide how to convert the signaling code.

- Andrew

-- 

Sent from my iPad

On Jun 6, 2016, at 7:14 PM, Michael Westfall <mwestfal@gemini.edu> wrote:

Hi Andrew,

Thanks for the explanation.

We're converting code from vxWorks to OSI (on top of RTEMS), and was wondering what to do with the semFlush() calls that are being used on binary semaphores.  Specifically, we're working on the Allen-Bradley DF1 driver.

Maybe what I should do is have a global counter that each thread increments before calling epicsEventWait(), and have the thread that calls epicsEventSignal() repeatedly signal and decrement the counter till it's zero..

Or is there a better way?

On Mon, Jun 6, 2016 at 4:35 PM, Andrew Johnson <anj@aps.anl.gov> wrote:

Hi Mike,

On 06/06/2016 01:39 PM, Michael Westfall wrote:
> The EPICS Application Developer's Guide says this about event signalling:
> "If multiple threads are waiting on the same event, only one of them
> will be woken when the event is signalled."
>
> How would one go about signalling ALL threads waiting on a particular
> event?
>
> This would be the equivalent of vxWorks semFlush().

Well, not quite. A semFlush() on VxWorks triggers a "thundering herd"
https://en.wikipedia.org/wiki/Thundering_herd_problem but doesn't seem
to allow any task to proceed, since it doesn't actually change the state
of the semaphore. We currently only support uni-processor (UP) on
VxWorks as well, so only one thread can actually proceed at once anyway.

If this were a binary semaphore you would therefore need to call
semGive() [which one to call first?] but only one of the waiting threads
could then return from the semTake() that they would be waiting in since
only one thread can own the semaphore at once; the others would all go
back to sleep even if they were all able to test the semaphore at the
same time (on a UP machine of course they can't).

If it's a counting semaphore instead, you could call semGive() multiple
times to allow multiple threads to return from their semTake() calls,
since there's no API for semGiveMany(int n), but that's going to wake
them up one at a time, not all at once.

The only way I can think of to wake up multiple threads at once would be
using a reader/writer semaphore, and have the semaphore owned by a
writer [taken using semWTake()] with all of the waiting threads sitting
in semRTake(). In this circumstance when the writer calls semGive() it
should then wake up and allow all of the waiting readers to proceed.

EPICS doesn't provide an API for a reader/writer semaphore, in fact we
don't currently provide any way of signalling to wake up more than one
thread at once. On a UP OS like VxWorks you can simulate it using a
regular epicsEvent (which is a binary semaphore on VxWorks) and have
each waiting thread check an associated "broadcast" flag immediately
after epicsEventWait() returns, and if that is set immediately call
epicsEventSignal() with the same ID to wake up the next thread.

This should have almost the same effect as waking all the threads at
once given that only one can actually be running on a UP system anyway,
although the epicsEventSignal() does trigger a system call so isn't free.

Why do you want to do this?

- Andrew

--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

--

Mike Westfall

Control Systems Software Engineer