Interthread Communications

Now, it is time to describe a multithreading program. If threads are not supposed to intercommunicate, the number of started threads doesn't matter. The difficulties arise when the operation of one thread depends on the activities of another thread. Here, different situations are possible. Consider everything in due order.

You have already encountered the situation, in which two parallel processes intercommunicated using global variables . To be more precise, one process was preparing data for another process. Here, there were no difficulties. One process changed the variable contents with the predefined periodicity, and another process read the data from this variable at another periodicity. If the data refresh period is smaller than the data read period, you can be almost sure that the second process will always obtain refreshed data. Sometimes the relationship between the data refresh and the data read period has no meaning, as in this example.

However, it is often impossible to obtain the data periodically. For example, the data may depend on the activity of the third process. How would the second process then know that the data have already been prepared for transmission? At first glance, the problem might be solved by introducing an additional variable. For instance, call this variable FLAG . Assume that if FLAG = 0 , the data are not ready; when FLAG = 1 , the data are ready. Then, the following easy scheme can be implemented:

 NO_DAT:             ...             MP  FLAG, 1             JNE NO_DAT             ...  ; Data transmission             ...             MOV FLAG, 0             ... 

As you probably guessed, this fragment is intended for the second thread. The first thread also must check the FLAG variable and, if FLAG = 0 , load new data into the variable and set the FLAG value to 1. This method is satisfactory when one process waits for another process to accomplish its task. In other words, the data are the result of the operation of that process. For example, suppose that you have started the compiler and another process waits for it to accomplish its operation before it outputs the results of its operation to some device. This situation occurs rather often.

However, what would happen if the data transmission process must be repeated multiple times? As can be easily noticed, this method will also work in a more difficult case. However, it is important to ensure that the second process changes the contents of the FLAG variable only after it receives the data and that the first process does the same thing only after it produces the data and loads them into the required variable. If this rule is not observed , collisions might occur. This would happen, for instance, if the second process didn't receive the data and the data were already changed.

This approach can be implemented in a more general case, when two threads (or two processes) must alternately access the same resource. As can be easily seen, this approach assumes that the resource is opened for one or to another process. If the problem is formulated in a different waythe process is either opened or closed for accesssome difficulties would arise. A situation is possible, in which both processes would wait for the resource to be opened. In other words, they would continuously check the FLAG variable ( CMP FLAG , 1 ). It might happen that they would attempt to access the resource simultaneously . Obviously, the need for some "mediator" would arise that would regulate access to the resource. For instance, such a mediator could send a message to one thread first and provide it access to the resource if it waits for its turn to access the resource. Then the same process would be repeated for the second thread.

This scheme is quite good, however, only if the threads access the resource alternately. If this requirement is not satisfied, a serious failure is possible. All considerations provided here aim to demonstrate that the problem of intercommunication among processes and threads and their synchronization is complicated and urgent for multitasking operating systems. Hence, such operating systems must have their own synchronization tools. [i]

Note 

It should be noticed that continuous polling of a certain variable in a loop can consume a considerable part of the CPU time. Naturally, this is not acceptable for a multitasking operating system.

The remainder of this chapter is dedicated to the synchronization tools of the Windows operating system.

[i] In MS-DOS, which wasn't a multitasking operating system, the problem of coordinating the operation of resident programs was especially urgent. Although the programmers writing such programs have achieved impressive results, concurrent operation of several resident programs often resulted in noticeable conflicts.



The Assembly Programming Master Book
The Assembly Programming Master Book
ISBN: 8170088178
EAN: 2147483647
Year: 2004
Pages: 140
Authors: Vlad Pirogov

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net