Critical sections explanation

[nameofuser1]

I wonder what the portMUX_INITIALIZER_UNLOCKED value actually means? I understand that spinlocks are used in order to synchronize cores when they need access to shared resource but should I always use portMUX_INITIALIZER_UNLOCKED when locking resource or I can set my own owner field in that structure?

Also it is totally not clear what happens if I call portENTER_CRITICAL_ISR inside interrupt handler and spinlock is already acquired by another core. Will it hang in ISR until primitive is released? Is it actually safe to call this macro from ISR since it essentially the same as portENTER_CRITICAL and it seems weird to me that behaviour is the same for ISR and task contexts?

Thanks!

[ESP_Sprite]

A spinlock is, unless you're debugging the things (in which case they get more complicated), not more than a simple int value, indicating lock status and the owner. In theory, there's nothing against pre-setting a certain owner and lock status when initializing; in that case, the correct CPU would have to release the spinlock without locking it. It's pretty unconventional, though.

Spinlock locks will always 'hang' (actually, spin) until the other core has unlocked the spinlock. portENTER_CRITICAL_ISR is not an exception to this. Hence these things being used to only protect processes that happen very quickly and do not depend on external things (like an SPI transaction completing): they can waste CPU time if there's contention.

In our implementation, portENTER_CRITICAL_ISR and portENTER_CRITICAL are the same, mostly because it makes it easy to write routines that can be used both from a task and an interrupt process. This is not true for some other FreeRTOS ports, though; they may implement the two differently.

[gfvalvo]

I realize that this is a really old thread. But, it seems the proper place to post my question.

My understanding of a Task or ISR "spinning" is that it's in a loop constantly trying to get ownership of the "lock". There are no context switches so nothing else runs on that core.

So, my question ... what happens if the "lock" that the spinning Task / ISR is waiting for is already owned by another Task / ISR on the SAME CORE? How will that "other" Task / ISR ever run in order to release the "lock" and make it available to the Task / ISR that's currently "spinning"?

Thanks.

[ESP_Sprite]

It won't. However, it's pretty hard to get into that state, as a critical section also disables interrupts on the local CPU, and FreeRTOS uses an interrupt to switch to another task.

[gfvalvo]

Ahhhh … got it. So, it acts kind of the same as a Critical Section would on a single-core, "Vanilla FreeRTOS" implementation for the local core but also makes the "other" core spin if and only if it also tries to acquire the lock.
Thanks.

[ESP_Sprite]

Exactly.