As is discussed in the documentation for the ser_sr24_set_event_handler() function, there are a few different types of event-notification mechanisms that can be used. Type 1 is probably the most common mechanism used, the callback mechanism, where the API calls one of your functions every time a hardware event occurs on the serial I/O board. Because the serial board API is multithreaded, (multithreaded means that a task in the API is executing in parallel with your main application, or virtually simultaneously) and this callback is made from the API's own thread, it could cause problems for some programs. One example of this is that Visual Basic applications cannot handle multithreaded callbacks. This isn't terribly surprising because of all that goes on behind the programmer's back in Visual Basic. This is why the included Visual Basic class module for the API internally uses the Type 3 event-notification method, which makes callbacks in a thread-safe way.
If you are programming in C or C++, there should be no problems caused directly by the language as there are in Visual Basic, but there are still several problems that you could run into just from what you do in your code. For example, if your event-handling callback and your main program both write to the same variable or data structure, then there is always a possibility that both could write to the same data structure at almost the same time. While this isn't a problem in itself, in many cases it could mean, for instance, that the value recently written by the main program was unintentionally overwritten by the callback. As an example, consider what might happen if both the main program and the callback try to add 10 to a variable at the same time (Let's call the variable X). If everything works out right, X will be 20 greater when both are done adding. However, this situation could occur:
In situations where there is a definite problem, there are some definite possible solutions. First, one of the most common solutions are thread synchronization solutions such as mutexes (available on both Linux and Windows). A mutex is used to prevent two threads (such as the main program and the callback) from accessing and modifying the same variable or structure at the same time. This prevents situations like the example described above. Another possible solution is to create a pipe (CreatePipe() on Windows or pipe() on Linux) for communication between the callback and the main program. Using this technique, the callback can write a message into the pipe, and the main program can read the message from the pipe whenever it has a chance. Also, on the Windows platform, you might want to look into event-notification Types 2 or 3. But once again remember, in many applications there will be very few or no problems caused by multithreading issues in the callback.
Back to Contents | Winford Engineering (2000) |