"An Ode to the Atomic TSL Instruction.
When running a process that is multi-threaded, look out for a problem universally dreaded. Should multiple threads each attempt to acquire shared data concurrently, then events can transpire such that bad luck with timing can leave you perplexed to see baffling results that you didn't expect.
Consider the following example for fun. Say two threads both grab 'x' and attempt to add 1. It seems adding '1' twice should be easy to do, when that effect you desire is an addition of two. But if you're unlucky then once both threads are done, then that effect it may be that you only add one. This is just one example but things can get worse, as threads interact results can get quite perverse. As they mess with shared data without coordination, they corrupt what they touch and wreak devastation. Should you find yourself in such a position, you're faced with what's known as a "race condition."
To reestablish order and reduce this frustration, you'll need to do proper thread synchronization. A means of protection, it seems quite conclusive, is to ensure access that's mutually exclusive. When some operation requires protection, that part of the code is called a "critical section." For multiple threads to keep everything straight, then while one makes a change all the others should wait. When the change is complete and the update is done, then one thread that's been waiting can now safely run. Then in turn when it's finished with it's operation, another is given access to the shared information. And likewise when it's done and ready to move on, then the next thread in line can be passed the baton.
The resource that's shared will be locked and unlocked, any thread that is waiting is said to be "blocked." At first blush it might seem this is easy to do; use an access flag, set it to '1' or set it to '2.' When a thread comes along and sees the flag is '1', it will set it to '2' and then work till it's done. Then it sets it to '1' so others will see, that the resource they share is once again free. And should a thread come along and find the flag equals '2', then it's clear in this scheme what that thread should do. It stops in its tracks and it blocks, and then it waits til the flag is back to '1' once again.
But just when you think you've got everything sorted, you'll find that this plan must be sadly aborted. For you see, no matter how good this all may have sounded, it turns out that our problem is only compounded. The flag that we're using for thread synchronization, is itself shared data much to our consternation. So the problem we initially set out to attack has not gone away; on the contrary, it's back.
Suppose two threads both alight, as it were, to examine the flags value, then events might occur such that both see a '1' and then both set a '2', which is exactly the misfortune we've been trying to eschew. But take heart there's a way this can be resolved, the design of your computer's CPU is involved.
The solution takes the form of an atomic directive, an indivisible instruction that will serve our objective. For it can check a value and then update it too; and do both of these in one step, not split into two. Both parts occur together, no interruptions between, which was the source of the trouble in the examples we've seen.
The Test-and-Set instruction will make our threads comport; it's our atomic operation, called T.S.L. for short. It will extricate us from our programmers despair; it sets the flag, but returns what used to be there.
So with one operation a thread could easily say whether it set the flag or just found it that way. Should other threads do the same, no matter how bad their luck, they cannot run the synchronization amok.
So the threads can use resources, play nice and share without their programmers pulling out their hair, and without the corruption of shared information.
All hail T.S.L. that has brought our salvation!
hellp