OSDev.org

I think I have to ask: what would spinlocks, or similar single, exclusive-access techniques be good for?

By now, I can only think about it being good for data that must be somehow shared and kept up to date to avoid corruption, with maybe the most obvious case being the filesystem, followed by memory management and task management, as well as communications like in networks, and also maybe synchronization tasks.

But I think, for very specific, but low level code (which seems to be a lot many cases), couldn't the complexity (bug-proneness) of "exclusive-access" algorithms on the data be reduced greatly if things were programmed in a stack approach where, for instance, a shared variable would have its state saved and restored in a stack by all of its users?

Optionally, keeping a record, an "ordered stack" of "callers" so that the last caller be the first to restore the state, which would constitute a classic, common LIFO stack (like the x86 one).

Wouldn't it be better to use a lightweight object-oriented approach as far as practical also, and make several concrete objects contain its "virtual machine" with its "global" shared variables? And finally, decide which "registers" in that object are intended to be used without the need to be saved but with the possibility to do so (which would mimic the freestyle usage of general-purpose CPU registers and could also free them a little) and which others should be saved at all times (and failing to do so would mimic the usage of special registers like stack pointers, general pointers, paging registers, on-memory system structures, control registers and the like which would make everything crash if someone fails to just set/save/restore them properly).

Or how does the x86 CPU manages to run an untold amount of multitasked, multithreaded code with only a few registers which basically save and restore states and a few state-saving structures that are switched to run each task/thread? I think it should be possible to simplify this matter with some design decisions, and these native structures really don't seem to have such complicated "spinlocks", so why don't do things similar to what those x86 structures do already with hardware-grade stability design ideas and with not much (at least not obvious) complexity?


I guess that this stack/hardware-like-virtual-structures approach would only be useful for a reasonable number of register-sized fields, but not for very big data structures (several kilobytes or more but indeed for anything less than that), for speed and space reasons.

Is that one of the reason of the existence of these exclusive access algorithms over the appliance of stack-based algorithms for saving and restoring states? Even so, wouldn't in that case be better to avoid using big shared structures in favor of register-style fields and platform-style structures (compact, efficient and full of consistent optimizations in every detail), and use exclusive-access algorithms only when really needed, like in filesystems and memory/task management, drivers, synchronization or the like?

think I have to ask: what would spinlocks, or similar single, exclusive-access techniques be good for?

Spinlocks are used in multicore OS's to prevent data being written by one core being read or written by another. Simple mutexes are okay for single core applications.

a shared variable would have its state saved and restored in a stack by all of its users?

How could that work ? If thread A saves the variable, then thread B modifies the variable, when A subsequently restores the variable, it overwrites the modified version.

The bottom line is that if 2 threads, on the same or separate cores can read/modify/write a variable, that variable must be locked during the read/modify/write phase. The lock can be some sort of bus locking (atomic operation) or a software lock (mutex, spinlock, disable interrupts etc.), but there must be a lock.

- gerryg400

Yes, you're right about wrongly outdating an old value into a variable instead of updating it in this way.

But I think, what if variables were designed to be treated by the program as general-purpose registers? In this way nobody will be normally worried about its previous value but more to interrupt a thread, start another and have this new thread finish a very fast task (which would be oriented to produce other data somewhere outside, not that much preserving/sharing the internal "virtual machine" registers with other modules) and then returning to the previous thread or another. Like in a situation where the true interest isn't saving or "synchronizing" the values, but instead do a task, using the "virtual registers" (global variables) found in a certain location internal to a module. It could very well be controlled by some kind of protocol.

Then the outside data can be locked before or some time after if desired, but it seems that it would require less complication with locks/mutexes, reducing them to only the final consumer data. Or maybe this is a wrong perception.


What about making a combination of all this as needed, or things like NOT locking the variable itself, but a single function or a set of functions which will be the only ones that will access the data, and lock them instead, either for reading the values, writing the values, or both, like with non-reentrant interrupts. It still would need an atomic operation to lock the function or family of functions, but wouldn't it be in some cases easier "locking" the code than locking the data?

And if the functions are used by more than one component, then there could be different "virtual" contexts which could be individually locked,
but still it seems that it would greatly reduce the average number of locks required.


I think it would make for a software lock trying to look more familiar like an x86 hardware lock, or would it still be up to fail? It seems to me that by some experimenting, there could be some proven cases where it makes more sense and things more natural, just like the main idea I was trying to present here, to try to "share" some variables just like the general processor registers for relevant variables that theoretically can be saved/restored without compromising consistency, and others, more fundamental, but that also would become fewer variables (trying not to spread critical sharing but grouping them in those fewer critical control structures), that undoubtly must be fully locked and its consistency preserved.

My SMP version of RDOS only uses spinlocks in the scheduler module (and only if more than one core is available). Device-drivers and other modules use EnterSection / LeaveSection, which are multiprocessor safe since they are implemented in the scheduler module with spinlocks if necessary.