So recap, the while loop either sees that no lock is present and skips ahead, or waits until there is no lock… then you lock the resource for your own use, do what you need, and unlock it so someone else can grab it.

Also @Kekoav, please note that the infinite while loop is just pseudocode. Since Flash is naturally single-threaded, you should never actually do that or it will hang. But you and Kyle are absolutely right that these are concepts implemented at the user level, to get some of the benefits of the thing without the real thing itself. I don’t pretend that this user-level code is as dependable or useful as a lower-level or real threadable semaphore, but neither is it entirely useless!

while (disk.isLocked())
{
wait();
}
disk.unlock();
disk.write();
disk.lock();

I like events, but having a true semaphore would be very helpful to sync up the few async calls without having to mess with a slew of events.

Semaphores are much more useful than a single lock, it should be noted that the one use case focused on this article is really a Mutex, or Binary semaphore. Semaphores really get interesting when combined to solve interesting problems, e.g. reader/writers producer/consumer, etc.

If I have a semaphore I want to wait() on it or it’s really just masquerading as a semaphore and is some other animal. I wish that AS3 could do it.

Nope, scripts are executed synchronously without blocking. There are some methods in the API that execute asynchronously, such as the timer or network access. But in general all code is executed every frame from start to finish.

I finally got around to reading this. It looks pretty useful and my brain is already swimming with other, wackier implementations of Semaphore.

I have some locks in KitchenSync already and i think this could beef it up. It would help the function sequences that already exist act even more like full-fledged command queues.

Great stuff!

The idea was to broadcast that the semaphore is becoming locked as it locks. This implementation allows you to lock it while it’s already locked, if you choose… but it’s not actually turning to the locked state unless it’s coming from 0 locks. That’s why i do _locks++ == 0. This is equivalent to doing

if (_locks == 0) { ... }
_locks++;

In other words, if you had 0 locks to begin with and you’re locking it, tell everyone you’re locked, but also increment the lock count after you check.

public function lock():void {
if (_locks++ == 0) {
dispatchEvent(new SemaphoreEvent(SemaphoreEvent.UNAVAILABLE));
}
}

Shouldn’t that be
if (_locks++ >= 0) ?

or if i’m wrong maybe it would be more clear to say
_locks ++
if (_locks == 1) {

It’s a higher-level semaphore for a higher-level language. As you rightly say, just because the AVM doesn’t execute ActionScript code in parallel doesn’t mean the concept is any less useful. It is an asynchronous language, and the order of code execution can sometimes be unpredictable if not parallel, for example code triggered by mouse events.

I have had a fun time experimenting with alternate ways of representing and dealing with asynchronous code in my applications, and this semaphore pattern works well together with my asynchronous token pattern as well. Keep an eye out for that article!

True semaphores were/are really used to prevent much more low level things, such as the “atomic” set of multiple machine instructions during a variable assignment, from being partially interrupted by a parallel set of instructions being executed on the same registers or memory space (such as a comparison on a shared variable from a different thread right in the middle of that variable being assigned by another thread). But, true semaphores are not something that more than a handful of low-level languages even fully implement, which means the ability to guarantee no race-conditions is difficult to achive.

The above is very helpful, especially in languages like AS and JS, which can implement semi-parallelism, where timers and blocks of code can cause the interpreter to jump around, and even be recursive/re-entrant. But actually, the concept here is more like a Semi-semaphore. :)

Still a valuable concept to get your head around. I used a similar concept in a flash project a few years back where I had an “Interval Manager” which managed all my setIntervals and managed which things were allowed to fire and which things were “locked” from firing while other things were running, etc.