wrong behavior binary semaphore

Sebastian Huber sebastian.huber at embedded-brains.de
Fri Nov 30 14:32:30 UTC 2018


On 30/11/2018 15:23, Arturo Perez Garcia wrote:
> Hello,
>
> I did more tests using the same source files. But modifying the 
> priority of the threads and the scheduling algorithm used in the 
> creation of the semaphore. What I was expecting (and what I need) is 
> this:
>
> task 1 start
> ld adq by kernel. kern_1
> ld rel by kernel. kern_1
> exe adq by kernel: kern_1
> sleeping kernel : kern_1
> task 2 start
> exe rel by kernel: kern_1
> ld adq by kernel. kern_2
> ld rel by kernel. kern_2
> exe adq by kernel: kern_1
> sleeping kernel : kern_1
> exe rel by kernel: kern_1
> exe adq by kernel: kern_2
> sleeping kernel : kern_2
> exe rel by kernel: kern_2
> exe adq by kernel: kern_1
> sleeping kernel : kern_1
> exe rel by kernel: kern_1
> exe adq by kernel: kern_2
> sleeping kernel : kern_2
>
> Where the semaphore is sequentially obtained and released by the same 
> thread each time it has been acquired. 

You have to consider that each rtems_semaphore_release() may make a 
higher priority thread ready (task 1) which wants to obtain the 
semaphore, so the output of the release is delayed until task 1 waits on 
something, e.g. the rtems_task_wake_after().

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the users mailing list