Emulating Windows Synchronization Objects
Recently, a client called to describe a specific problem, the general aspects of which are relevant to all script and Windows Script Host (WSH) developers. The problem per se—ensuring synchronization between multiple tasks—wasn't particularly difficult, but the range of tools I needed to use to solve it made the process difficult.
Synchronizing a few tasks in a Win32 application, even in a Microsoft Visual Basic (VB) application, is a matter of calling a couple of API functions: one for creating an appropriate event object and one for putting the calling thread on standby until the OS wakes it up when the event is signaled. So, if you can use Visual C++ (VC++) or VB, the process is easy. However, if—as in this case—the surrounding environment is WSH and VBScript is the language of choice, you must resort to emulation and a bit of creativity.
The Synchronization Problem
My client described the problem thusly: One WSH script has to spawn a few other scripts that use existing executables. The main script has to stop and wait for all the spawned processes to terminate. (The stop-and-wait action is called a blocking wait.) If an error occurs in any child process, the whole operation must be considered canceled, and ideally the overall outcome is as if nothing ever happened.
Two underlying patterns surface after careful analysis of the problem. One pattern is that the script must stop execution and be able to wait for the OS to signal multiple objects before the script continues. This pattern is common in multithreaded programming, and any development kit for the environment usually provides a native tool for it. Win32 is no exception, but WSH isn't full Win32.
The other pattern is the transactional behavior that the user expects from the main script. The spawned scripts are considered the internal operations of a transaction, and the main script waking up after all the children terminate is a sort of automatic commit. (Commit is the command that successfully terminates a transaction, accepting all the results that have been generated.) One user requirement is for a script-specific mechanism to provide for rollback—namely, the ability to cancel all the results generated and invalidate the entire operation.
The Run Method
As a seasoned user of the WSH object model, you probably know that the WshShell object's Run method is the WSH programmatic counterpart of the Start menu's Run dialog box. You can use the Run method to spawn an external program with several possible settings. The full signature for the method looks like this:
WshShell.Run(strCommand, _
[intWindowStyle], _
[bWaitOnReturn])
The first argument (strCommand) is the command name of the executable to start, including its arguments. Next, you can specify the style of the program's main window [int Window Style] and—what really matters here —a Boolean value to specify whether the calling script has to undergo a blocking wait until the spawned executable terminates.
By default, the bWaitOnReturn flag is set to False, which means that the execution is asynchronous. To use the Run method to run a WSH script, use the syntax
Set shell = _
CreateObject("WScript.Shell")
shell.Run "wscript.exe test.vbs"
When the bWaitOnReturn argument is set to True, the script that spawns the child process waits for that process to terminate, then lets the next instruction proceed.
You might think that the Run method could solve my client's problem. The Run method can synchronize the caller script with the spawned application and signal the script when the child process terminates. However, the Run method doesn't let you synchronize more than one child process. To solve the problem, you need to emulate the behavior of those low-level constructs that, in Win32, let you synchronize the evolution of a process with system- and application-level events. Here are the requirements for emulating this behavior:
- Without dramatically affecting the load on the CPU, stop the execution of the main script until the spawned processes terminate.
- Detect when a given executable has finished.
- Decide whether to accept the results that have been generated.
As the second requirement hints, some form of interaction with the spawned process is necessary. If you can control the source code of the script or the executable, that's fine. Otherwise, you can wrap the program in a VBScript program spawned with the bWaitOnReturn flag turned on.