On 06/06/2016 19:57, Sebastian Huber wrote:
On 04/06/16 08:16, Chris Johns wrote:
On 03/06/2016 23:44, Sebastian Huber wrote:
On 03/06/16 15:40, Joel Sherrill wrote:
My concern is that this will break existing programs that used them for
condition synchronization.
These applications are brok
On 04/06/16 08:16, Chris Johns wrote:
On 03/06/2016 23:44, Sebastian Huber wrote:
On 03/06/16 15:40, Joel Sherrill wrote:
My concern is that this will break existing programs that used them for
condition synchronization.
These applications are broken since you can obtain the
RTEMS_BINARY_SE
On 03/06/2016 23:44, Sebastian Huber wrote:
On 03/06/16 15:40, Joel Sherrill wrote:
My concern is that this will break existing programs that used them for
condition synchronization.
These applications are broken since you can obtain the
RTEMS_BINARY_SEMAPHORE recursively.
Did you check if
On 03/06/16 15:40, Joel Sherrill wrote:
My concern is that this will break existing programs that used them for
condition synchronization.
These applications are broken since you can obtain the
RTEMS_BINARY_SEMAPHORE recursively.
This just requires us to be vigilant to answer questions whe
My concern is that this will break existing programs that used them for
condition synchronization.
This just requires us to be vigilant to answer questions when things
break.
On Fri, Jun 3, 2016 at 8:37 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> The Classic binary semapho
The Classic binary semaphores without a locking protocol
(RTEMS_BINARY_SEMAPHORE) 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 wa
