On 07/06/16 09:48, Chris Johns wrote:
On 07/06/2016 17:31, Sebastian Huber wrote:
Yes, its definitely worth to discuss this. My preferred solution would
be to go away from the objects and treat the Classic objects as a legacy
component.
I am not sure about the term legacy component but I see
On 07/06/2016 17:31, Sebastian Huber wrote:
Yes, its definitely worth to discuss this. My preferred solution would
be to go away from the objects and treat the Classic objects as a legacy
component.
I am not sure about the term legacy component but I see what you are
saying. For new applicatio
On 06/06/16 14:05, Pavel Pisa wrote:
Hello Sebastian,
On Monday 06 of June 2016 13:12:52 Sebastian Huber wrote:
But if the RTEMS API is getting touched then in this regard I rise
again my opinion that semaphores and mutexes should be strictly
separated. This would prevent confusion and h
Hello Sebastian,
On Monday 06 of June 2016 13:12:52 Sebastian Huber wrote:
> > But if the RTEMS API is getting touched then in this regard I rise
> > again my opinion that semaphores and mutexes should be strictly
> > separated. This would prevent confusion and help to static code analyze
> >
Hello Pavel,
On 04/06/16 11:57, Pavel Pisa wrote:
Hello Sebastian and others,
generally, I am highly thankfull for all that hard work done to bring
RTEMS to multicore SoC era and all that with attempt to keep RTEMS
API compatible with existing applications.
On Friday 03 of June 2016 15:26:15 S
Hello Sebastian and others,
generally, I am highly thankfull for all that hard work done to bring
RTEMS to multicore SoC era and all that with attempt to keep RTEMS
API compatible with existing applications.
On Friday 03 of June 2016 15:26:15 Sebastian Huber wrote:
> On 03/06/16 15:24, Joel Sherr
On 03/06/16 15:24, Joel Sherrill wrote:
Binary semaphores with no protocol can be used for condition
synchronization. This was described way back by Dijkstra. Usually the
binary semaphore starts locked, a thread will then block upon an
attempt to lock it. An ISO or other thread can release or f
Binary semaphores with no protocol can be used for condition
synchronization. This was described way back by Dijkstra. Usually the
binary semaphore starts locked, a thread will then block upon an attempt to
lock it. An ISO or other thread can release or flush to announce the
condition.
This is a n
This changes undocumented behavior. It might be good to add a note to
the (new) doc that only a lock owner is allowed to release. I guess
the only plausible reason one would want the other behavior is for
some kind of deadlock detection and "recovery", but I can't see that
working correctly in the
On 03/06/16 15:06, Gedare Bloom wrote:
This changes undocumented behavior. It might be good to add a note to
the (new) doc that only a lock owner is allowed to release. I guess
the only plausible reason one would want the other behavior is for
some kind of deadlock detection and "recovery", but I
The Classic binary semaphores without a locking protocol could be
released by everyone, e.g. in contrast to the POSIX mutexes (all
variants) or the Classic binary semphores with priority inheritance or
ceiling there was no owner check in the release path.
This behaviour was a bit unexpected and no
11 matches
Mail list logo
