Ack! (Was: proper data synchronization)

I had an entire post all written up about nice ways to handle data synchronization with threads in REALbasic. But then hell broke loose and I managed to lose the entire post. Gotta love that!

In any event, here's a half-hearted attempt at explaining things in a very quick and dirty manner. However, I'll make up for the lack of detail in the post by giving a sample project that demonstrates instead.

Problem:
It's hard to keep track of what semaphores go with which resource and things of that nature. It's usually quite easy to forget about the semaphore altogether and just access the data directly. And almost every data protection scheme you can come up with won't work in a generic manner because each resource and situation is slightly different.

Solution:
Make an easy way for users to synchronize data. Yes, it still requires the user to remember that they need to care. That's a very tough problem to solve though. We're just going to try to make it easy for users to do and hope they remember to do it.

So how easy do we want this to be? Simple -- two calls to take care of everything.

Essentially, we want the user to be able to say:

Sync( some data item )

  Do some things

  Do some more things

  This takes a long time

End Sync( some data item )

So we're going to make a module that let's the user do just that! We're going to use a Dictionary to store the locking mechanism of choice (which is a Semaphore), where the keys in the dictionary is just the object which we wish to synchronize (and the value is the semaphore itself). This works out really nicely because the Dictionary will store unique semaphore for unique items. So if you are using the same object to sync, then you will be getting the same semaphore signalled. If you're using different objects, then you get different semaphores (which makes sense because the objects are different references).
[rbcode]
Protected Sub Lock(v as Variant)
// The user wants to lock access to the
// data passed in. So the first thing we
// need to do is see whether our Dictionary
// already has a semaphore for this data.

if mResources = nil then mResources = new Dictionary

if mResources.HasKey( v ) then
// We already have this key in the dictionary. So
// we want to access the value, which is a semaphore
// object.
dim sem as Semaphore = mResources.Value( v )

// Now we want to signal the semaphore. This
// will cause the thread to block if some other
// thread has already accessed this same variant.
sem.Signal

// Now the thread can access the resource, so
// we're done here.
return
end if

// If we got here, then there's no key for
// this Variant. So make one!
dim sem as new Semaphore
mResources.Value( v ) = sem

// And lock it
sem.Signal

// Now we're done
End Sub

Protected Sub EndLock(v as Variant)
// The user is done accessing
// this particular resource, so we
// need to dig it out of the Dictionary
// and release it

// Sanity check #1
if mResources = nil then
dim exp as new RuntimeException
exp.Message = "You have called EndLock before ever calling Lock"
raise exp

return
end if

// Sanity check #2
if not mResources.HasKey( v ) then
dim exp as new RuntimeException
exp.Message = "You have called EndLock before ever calling Lock for this particular object"
raise exp

return
end if

// Now we know that we've got the
// semaphore in our dictionary, so
// grab it out and release it.
dim sem as Semaphore = mResources.Value( v )
sem.Release

// We're done!
End Sub[/rbcode]
Ta da! That's all these is to it. When you want to use this code, it looks very similar to what we outlined before:[rbcode]
Sync.Lock( someDataItem )
DoSomeThings( someDataItem )
DoSomeMoreThings( someDataItem )
someDataItem.ThisTakesALongTime
Sync.EndLock( someDataItem )[/rbcode]
Some things to note about this method though -- it's still possible to get your locks out of sync. If you call Sync.Lock and forget to call Sync.EndLock, then you are really going to be hosed. You can run into this situation pretty easily by accidentally calling Return from the middle of your sync'ed operation.

However, you're also no worse off than you would be if you used Semaphores directly. This is just an easier mechanism since you don't need to bother keeping track of the semaphores at all.

Sorry for the total lack of decent descriptions and information, but I don't have the time to rewrite the hour's worth of work I just lost. :-P