Skip to contentSkip to conversation

Thread preemption and rte_ring

DISCUSSION Dmitry Vyal 2 participants 2 messages Nov 5, 2013 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

Hello,

Documentation for rte_ring says: the ring implementation is not preemptable. A lcore must not be interrupted by another task that uses the same ring. What does it precisely mean? Must all the producers and consumers be non-preemptive? Can we relax that restriction somehow? Say, can I have multiple non-preemptive writers running on dedicated cores and a single reader running as a regular Linux thread?

Thanks,
Dmitry

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw

Hello Dmitry,

Quoted 4 lines

Documentation for rte_ring says: the ring implementation is not preemptable. A lcore must not be interrupted by another task that uses the same ring. What does it precisely mean? Must all the producers and consumers be non-preemptive?

The "non-preemptive" constraint means:

- a pthread doing multi-producers enqueues on a given ring must not be preempted by another pthread doing a multi-producer enqueue on the same ring.
- a pthread doing multi-consumers dequeues on a given ring must not be preempted by another pthread doing a multi-consumer dequeue on the same ring.

Bypassing this constraints may cause the 2nd pthread to spin until the 1st one is scheduled again.
Moreover, if the 1st pthread is preempted by a context that has an higher priority (for instance a kernel thread), it can even cause a dead lock.

Quoted 3 lines

Can we relax that restriction somehow? Say,
can I have multiple non-preemptive writers running on dedicated cores and a single reader running as a regular Linux thread?

Yes, this should work.

Regards,
Olivier