On 5/29/2010 1:14 PM, Chip Orange wrote:
Oh, for instance, get some info out of a particular dictionary object. I test if it exists, and then when I go to get info out of it, I get an error because it no longer exists, because some other event handler has removed it (as it should); but these types of conflicts where objects are created and modified and deleted by more than one thread really could use some atomic control, and I was wondering if anyone had already solved this issue.
Are you talking about two event handlers in the same script? If so, they don't run in separate threads. ActiveScript scripts only have one thread. Normally, everything you do would be atomic. However, since the Dictionary object lives in a different process (in Vista and above, anyway) the call to access it might let the second event handler call sneak in while the first one is waiting for a reply from the other process.
If you used a local boolean variable to control access, changes to that variable's state should be sufficiently atomic. However, because the problem isn't actually multiple threads but re-entrancy on the same thread, you have to figure out what you'll do in that other event handler if it can't get acquire a lock on the Dictionary object. It can't just block, because that'll cause a deadlock. That, unfortunately, is not an easy problem to solve. One thing you could do is queue a function that'll try again later, but then you run the risk that some third handler might fire and try to use the object after it should have been deleted by the second, and so on. Good luck with that part of it; this is the stuff that keeps programmers up nights.
There is a related topic having to do with multiple scripts trying to access the same shared object. In that case, you really are talking about synchronizing multiple threads, but you're also presumably talking about the possibility of having two scripts from two or even three different authors involved. When that's likely, the synchronization should be part of the shared object's public interface. If the shared object is implemented by an ActiveScript script, it will also run in a single thread, which means (again) that you can't make it block on failure, so in this case the calling script needs to block (or handle the failure to acquire a lock some other way, possibly by rescheduling the attempt. That depends on what your caller wants to do and whether it itself is in a situation that can't block, such as a keyboard event handler.) So, in addition to whatever other properties and methods your shared object might have, it would also have methods like "AttemptLock" and "Unlock." In the simplest case, there's no enforcement of any of this. An unscrupulous script could call Unlock without first succeeding at AttemptLock, or could just skip calling the lock functions at all, and that would break things. But as long as all of the object's clients adhere to the contract, it'd work. (This is just like critical sections in Win32 API programming: acquiring one is optional, and if even one thread fails to do so before working with a nominally protected resource, the whole house of cards falls down.)
