Re: Modifying bit array locking behavior

Mitsis, Peter

Minor correction … I found a couple other places in-tree where we use bit arrays. These are in cmsis_thread.c and kernel/mmu.c. Assuming that this locking proposal goes forward, then those two files would also be impacted.


Peter Mitsis


From: devel@... <devel@...> On Behalf Of Mitsis, Peter
Sent: Monday, July 4, 2022 9:43 AM
To: devel@...
Subject: [Zephyr-devel] Modifying bit array locking behavior




At the current time, bit arrays (see sys/bitarray.h and lib/os/bitarray.c for implementation) utilize a spin-lock to protect the contents from other execution contexts. As a bit array is a basic data structure that does not always need locking protection, I would like to hoist that locking out of the bit array routines and have that done by the caller (as is the case for other data types such as linked lists). This would change the behavior and semantics of bit arrays from their current paradigm, and would likely have some impacts beyond what I currently know about.


As I understand things, the in-tree use of bit arrays is currently confined to memory blocks (sys/mem_blocks.h and kernel/mem_blocks.c). Such a locking change would naturally impact memory block implementation as the locking would be hoisted out from bit arrays into the memory block routines that call the bit array routines. Out-of-tree use is an unknown, and it is reasonable to assume that there are projects that would be affected by this. To what extent that would be the case—I do not know. And there may be challenges to getting the word out about the behavior change, but as bit-arrays were introduced in April 2021 I would  guess that their adoption would not be  too widespread as to make it too much of a burden.


Thoughts? Comments?


Peter Mitsis

Join to automatically receive all group messages.