English Script Request

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 conspire, such that bad luck with timing can leave you perplexed, to see baffling results, that you didn't expect.
Consider the follow 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 it 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 threat 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's called a "critical section". For multiple threads to keep everything straight, 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's 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 the thread comes along, it 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, 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 ashoo(?).
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, and indivisible instruction that will serve our objection. 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 in 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, plain ice(?) and share, without their programmers, pulling out their hair.
And without the corruption of shared information, all hail TSL, that has brought our salvation.