Product(s) :Plug-In Boards: all KPCI, KPCMCIA and many ISA
Question : How do I use DriverLINX in a multi-threaded application?
Answer: DriverLINX is designed to allow multiple clients access a single data-acquisition board. DriverLINX clients can be different processes or even different threads. If clients contend* for the same hardware resource, DriverLINX ensures that tasks are not interrupted (except by an explicit initialize operation by the same process) and guarantees that a request either succeeds in creating a task or receives a Device Busy error. In simple cases, where clients are not in contention for the same hardware resource, DriverLINX simply serializes the commands to the board and all requests succeed.
To write an application that utilizes these features, a controller thread should call OpenDriverLINX(), initialize the device, and when all worker threads are done, call CloseDriverLINX(). Each worker thread that accesses the device, should call OpenDriverLINX() to obtain their own handle to the driver, call DriverLINX() to perform data-acquisition operations and call CloseDriverLINX() when done. Note: any thread in the same process can initialize the device or a subsystem, causing all active tasks to be terminated.
There is some more housekeeping steps required of a multi-threaded DriverLINX application. Because DriverLINX uses COM with the apartment-threaded model internally, it initializes COM with the CoInitialize() function when first called by a client process. However, COM requires each thread to call CoInitialize() and CoUninitialize(). Therefore, each thread that uses DriverLINX should use the apartment-threaded model and begin and end with these calls.
Further, if a thread uses the Service Request API to create continuous background (asynchronous) tasks, it must also create a window--which could be hidden--and run a window message loop to handle DriverLINX messages.
In summary, DriverLINX can be used in multi-threaded applications. For simple, polled, worker threads that use separate resources of the board, it is quite straightforward. In other cases, the complexity introduced by multi-threading may best be solved by having only one thread interact with DriverLINX and use Windows synchronization primitives to coordinate the access by worker threads.
*This refers to the Service Request API. The alternate, Direct I/O ActiveX object for digital I/O boards such as PIO-24, KPCI-PIO24, KPCI-3160 or KPCI-PDISO8A, supports polled mode only and therefore does not resolve contention between clients. However, the usage guidelines for both APIs in multi-threaded applications are the same.