Atomic variable in deadlock

RE: Atomic variable in deadlock

Vidar Berg — Mon, 29 Jan 2024 13:58:06 GMT

Hi Christian,

It seems I might have been too quick to conclude that it was a priority issue, considering that you observed the same behavior after yielding from the receiver thread. Maybe it was only part of the issue. Zephyr mutexes support both 'Reentrant Locking' and 'Priority Inheritance'.

Best regards,

Vidar

RE: Atomic variable in deadlock

Lorenz898989 — Sat, 27 Jan 2024 14:49:09 GMT

Hi Vidar, thank you for your reply.

To prove that everything else in the code works I replaced the atomic variables with a mutex: in this case everything works (I received more than 10 billion BLE messages from multiple transmitters handling them without problems).

How come with mutex it works and with atomic variables it does not?

To make it even more curious:
If in the while (!atomic_cas) of waiting I put a k_yeld() or a k_usleep() it keeps freezing, BUT if I put a printk(""); then it never freezes.

I had also speculated that it might be a priority issue however I am not convinced: if I stop sending BLE messages after it freezes it keeps getting frozen

The structure you propose is nice and I will certainly look at it more carefully.

Best regards

Cristian

RE: Atomic variable in deadlock

Vidar Berg — Sat, 27 Jan 2024 12:31:51 GMT

Hello,

Did you consider using the FIFO implementation from Zephyr or the 'Data FIFO' from NRF before making your own? It seems like it would be better to use something that has already been well tested. Anyway, the problem here is that your higher priority BLE receiver thread is blocking your main thread, resulting in the lock never being released.

Best regards,

Vidar