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:

		RTEMS_LOCAL, &t_matmul_id

		RTEMS_LOCAL, &t_inout_id

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.
> Thanks.
> 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 mailing list