Page 2 of 4   « previous page   next page »

For a real-world example, imagine that you place an order at your local electronic store for the latest super-cool MP3 player, but the product is currently out-of-stock. The sales associate however promises they will receive it within the next 10 days. One possible -- but inefficient -- way for you to get your hands on the product is to call the store every hour or so to find out whether or not it has arrived. This would waste a lot of time for both you and the store and is what you would define as a polling mechanism.

Another and better mechanism would be for the sales associate to phone you once they receive the product. This is a notification mechanism and as you can see, is far more efficient. We will take this mechanism and adapt it to our game board example.

Imagine the following context: It is the computer's turn to compute the next move. Your Lingo code calls your multithreaded Xtra, which creates a new thread (the "secondary thread"), which calls the game engine with the appropriate parameters, and returns control to Director and your Lingo code in the main calling thread. While the game engine is computing its best next move in the secondary thread, you are free to make your Lingo code do whatever you feel is appropriate, for example you could display an animation, respond to user interactions, etc. Your Lingo code wouldn't need to be different than any other ordinary Lingo code and thus can be architected exactly the way you want it. Director and your Lingo code would obviously run in the main thread.

When the game engine completes its computation, it and returns to your multithreaded Xtra, the Xtra would then call a handler in Director which you would have designated to take over after the next move's result is delivered. The game Xtra engine would do this in the secondary thread as it would not have access to the main thread at this point.

Unfortunately, this approach would inevitably lead to a crash in Director. This is because Director is not protected against reentrancy: you cannot call a Director method from anywhere else other than the main thread. You would have to find a way to catch its main thread first.

To illustrate this mechanism with our real-world example, having the secondary thread directly call the completion handler in your Director movie would be equivalent to the sales associate calling to notify you that your MP3 player has arrived, and expecting you to take delivery right away even though you may be in the shower at that time of the call and not in a position to instantaneously respond to his or her call.

Subtle Multithreading: the Producer/Consumer Model
Let's improve the notification mechanism introduced above. Let's have the sales associate call and leave a voicemail informing you that your MP3 Player has arrived. This would allow you to retrieve and respond to the voicemail in the order that best suits your schedule.

To do the above in a software program, you would need to implement a Producer/Consumer communication model. The main thread (Director) would be the Consumer. The secondary thread would be the Producer. There would be a FIFO (First-In First-Out) message queue to coordinate their efforts. The message queue works exactly like the answering machine in our real-world example between the sales associate (the Producer) and you (the Consumer). When the Producer has something to signal to the Consumer, it adds it to the message queue. Every time the Consumer has spare time, it checks the queue to see if something is waiting for it. When it finds a message, it retrieves it and processes it.

In our board game example, this translates to the following sequence: When it's the computer's turn to make a move, your Lingo calls the Xtra which immediately returns control to your Lingo. While your Lingo code is free to interact with the user, the Xtra spawns a secondary thread and sends it to the game engine for processing. When the game engine is ready with its next move, it posts the result to the message queue using the secondary thread (the only thread it has access to). communicates it to the Xtra in the secondary thread. The Xtra posts a message to the main thread in the message queue. The main thread then picks up the message and processes it.

While this mechanism is only explained in the context of the completion of a computation, it equally applies to the retrieval of the progress of a task or its error condition.

Making it Bullet-Proof
To make sure your threads work harmoniously together, you have to make sure the following conditions are met.

Page 2 of 4   « previous page   next page »