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 that 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 that adding 1 twice should be easy to do.
The net effect you desire is addition of 2,
but if you're unlucky, then once both threads are done
the net effect it may be that you only have one
This is just one example, but things could get worse,
as threads interact, results can get quite perverse.
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 one.
It seems adding one twice should be easy to do; the net effect you desire is addition of two.
But if you’re unlucky, then once both threads are done, the net 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.
The 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’s 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.
And in turn, when it’s finished with its 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 one or set it to two.
When a thread comes along and sees the flag is one, it will set it to two and then work ‘til it’s done.
Then it sets it to one so that others may see that the resource they share is once again free.
And should a thread come along and find the flag equals two, 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 one 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 that two threads both alight, as it were, to examine the flag’s value – then events might occur
Such that both see a one, and then both set a two, which is exactly the misfortune we’ve been trying to eschew.
But take heart, there’s a way that 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 it 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 “TSL” for short.
It will extricate us from our programmer’s despair. It sets the flag but returns what used to be there.
So, with one operation, a thread can 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 amuck.
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 “TSL,” that has brought our salvation!
