Re: epicsEvent (posix implementation) bug ?

[Eric Norum <wenorum@lbl.gov>]

This topic seems to have shifted a little.

It started out as discussing the semantics of epicsMessageQueue with multiple readers.  The shift to the semantics of epicsEvent with multiple waiters is a result of the POSIX implementation of epicsMessageQueue.

I think that both issues are worthy of discussion and that there's likely more than one place in the appDevGuide that could use such a statement.

FWIW, both vxWorks and RTEMS currently provide FIFO semantics for both epicsMessageQueue with multiple readers and epicsEvent with multiple waiters.....

On Jan 31, 2011, at 9:09 AM, Jeff Hill wrote:

Ø  Not sure about windows, but since priority inversion is a major issue only for

Ø  systems with strict priority-based scheduling I'm not sure that it's that big a

Ø  deal there anyhow.

 

So I can confirm that Windows does not support such options, and agree that this is probably because it isn’t that type of (strict priority scheduled) OS. I am going to guess that Windows CE also doesn’t allow for such options.

 

Perhaps the application developers guide should say something like this.

 

“Where possible and reasonably efficient the OS specific implementation of the event semaphore should select options which provide priority based queuing, but portable source codes who are consumers of the epicsEvent interface should not depend of this feature nor allow its absence to substantially change their run-time behavior.”

-- 
Eric Norum
wenorum@lbl.gov