More threading fun!

One concept in threads programming is the idea of a "future." The concept is really quite simple to think about, but poses an interesting problem in some languages.

Basically, a future is a special data type that promises to have a value set sometime in the future. The easiest way to think about this is to think in terms of when access occurs.

If threadA comes and calls Future.Set, everything just continues executing as normal. Then, if threadB comes and called Future.Get, the value has been initialized, so everything keeps moving right along.

However, if threadB were to come along and call Future.Get, but that future is uninitialized (no one has Set the value yet), then threadB would be put to sleep until the future becomes initialized.

In this fashion, a future is like a promise that a particular property will always be initialized before you can actually use it.

Pretty neat concept, eh?

REALbasic has no built-in concept of a Futures data type. However, the resourceful programmer can easily make a Future class to meet their needs. Let's break the problem down into its individual parts to arrive at a solution.

1. We need a way to tell when a value has been initialized. That's simple -- we can just use a boolean flag that gets set to true when someone assigns to a property.




2. So now we need a way to tell when someone assigns to a property so that we can set our flag. That's easy too -- we can use a computed property. That has a Get and Set method that we can utilize.
3. Now we need a way to tell when the user tries to access the property. We've already solved this however -- we're going to use a computed property.




4. We need some way to lock the calling thread if it calls Get and the value isn't initialized yet. Again, we can do this without worry. REALbasic has a Semaphore object which we can use.




5. We need a way to unlock threads once the value has been set. Again, we'll be using the Semaphore.

Because of REALbasic's cooperative threading, we don't have to worry about what happens if a thread pre-empts another one in the middle of some operation. So it sounds like we can easily do exactly what we're after (which is what I'd hope since I don't usually write blog posts the trail off into mumblings). Awesome! Let's check out this class.
[rbcode]
Class Future
// We set this to true once we initialize
// the value.
Private mInitialized As Boolean

// This is the lock used by the Value computed
// property's getter and setter.
Private mLock As Semaphore

// This is the backing storage for the class. It's used
// by the Value computed property
Private mValue As Variant

Sub Constructor()
// The object starts out uninitialized
mInitialized = false

// We want to make a new semaphore
// so that we can block threads when
// needed.
mLock = new Semaphore

// The semaphore starts out originally
// locked so that any thread calling Get
// will have to block. If someone has
// already called Set though, then the
// call to Get won't ever try to lock the
// semaphore, so it's fine.
mLock.Signal
End Sub

Property Value As Variant
Function Get() as Variant
// If the value hasn't been initialized
// yet, then we need to lock ourselves
// until someone calls Set
if not mInitialized then mLock.Signal

// At this point, the value is initialized, so
// we can just return it
return mValue
End Get

Sub Set( vakue as Variant )
// Set the value
mValue = value

if not mInitialized then
// The value is now initialized, so flag it
mInitialized = true

// We need to release as many locks as we can
// because there could be multiple locks obtained
// from other threads calling Get.
while not mLock.TrySignal
mLock.Release
wend

// At this point, we own the lock again, but we
// know there's only one lock. So release it. This
// means that the semaphore is now back to the
// unlocked state
mLock.Release
end if
End Set
End Property
End Class[/rbcode]
Well that wasn't so hard, now was it? Everything worked out just like we said it would. If a thread attempts to access the Value computed property before it's been initialized, that thread will be locked by the Semaphore. When a thread finally gets around to setting the Value computed property, all other threads that were locked are then unlocked (so they can finally access the value).

I've created a simple sample project called FuturesExample which demonstrates this class in action. When you run this project, open up your system's DebugLog viewer as well. If you click on the first two push buttons, you'll see that nothing interesting happens. That's because they're both locked! Pressing the third button causes the Future to be initialized, where upon the other threads wake up and can do their thing.

And that's your neat geek trick for the day. You can thank Mars for getting me to think about this problem and come up with the solution. He and I had a very interesting discussion today about some of the future (no pun intended) directions we'd like to take threads in. This just so happened to be the last thing we talked about, and one of the things that was possible to implement in REALbasic without any framework help.