Task sync problems related with binary semaphore and cache memories
Arturo Perez Garcia
arturo.perez at upm.es
Wed Nov 28 10:30:17 UTC 2018
Disabling the caches don't fixe the problem, I was wrong.
Maybe I'm initializing wrongly the RTEMS objects.
In the Init task I create the binary semaphore:
rtems_semaphore_create(a3_sem_name, 1, RTEMS_BINARY_SEMAPHORE |
RTEMS_FIFO | RTEMS_LOCAL, 0, &a3_sem_id);
Then I create 2 tasks with different priority:
t_matmul_name, 1, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_PREEMPT,
t_inout_name, 2, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_PREEMPT,
The tasks must be synchronized through the semaphore, but they are not.
The semaphore is acquired by both tasks consecutively before it has been
I suppose that it is due to an error in my BSP implementation, but I
don't know how to test it.
El 2018-11-28 11:18, Arturo Perez Garcia escribió:
> RTEMS is running in the R5 processors in lockstep mode, hence it is
> not an SMP configuration.
> El 2018-11-27 14:45, Sebastian Huber escribió:
>> On 27/11/2018 13:23, Arturo Perez Garcia wrote:
>>> Hi, I have been facing thread synchronization problems.
>>> I was trying to synchronize two threads using a binary semaphore to
>>> protect critical parts of the code. Today I realized that the
>>> semaphore was been acquired sequentially by both threads before It
>>> was released by any of them. This behavior has been fixed when I have
>>> disabled the cache memories, either the data cache or instruction
>>> cache. Could you give me some hint about this??
>>> I'm using our own BSP for the zcu102, which was generated by
>>> modifying the xilinx-zynq bsp for the RTEMS release 4.11.3. This
>>> behavior can be related to a wrong implementation of the BSP??
>> Please run the smplock01 and smpatomic01 on your board. I guess the
>> cache snooping is not enabled.
>> SMP is experimental in RTEMS 4.11. I would use the RTEMS master.
Arturo Perez Garcia - arturo.perez at upm.es
Center of Industrial Electronics
Universidad Politecnica de Madrid
More information about the users