<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi all,</div><div><br></div><div>I finished my work to add MCPI support to an octa-core TI DSP for RTEMS. I reused the shared memory template from the *shmdr* directory.</div><div><br></div><div>A problem occurs when tested on 2 cores. Say, core 0 creates a *GLOBAL* message queue. Core 1 plays as the sender and core 0 the receiver. Everything goes well: core 0 receives a message instantly after core 1 sends one. However, when I switch their roles, things go beyond expectation: core 1 does not receive any until core 0 finishes its sending. The worst case is that when core 0 keeps on sending messages, core 1 will stay blocked and the task gets starved.</div><div><br></div><div>I think core 0 takes the preemptive opportunities to always manipulate global objects created on itself. For a stopgap, I had to rely upon hardcoded delay to meet the anticipation ("ABABAB" pattern between two nodes). But it is brittle because the latency of cache access and shared memory access may vary on different evaluation boards.</div><div><br></div><div>Was I porting it wrong? Or is there already a solution to this?</div><div><br></div><div>Maxul</div></div></div></div></div></div>