ODBC in Multi-Threaded Environments (Thread Safety)

Overview

In Version 2.5, Microsoft began to introduce elements to ODBC dealing with more advanced operating environments. ODBC drivers for multi-threaded operating systems are required to be thread safe. It must be possible for more than one application thread to share the same ODBC handle.

The extent of this requirement is unclear. At the very least, it seems to require that simultaneous use of the same handle by more than one thread would not produce internal inconsistencies in the handle. In general, use of a handle by multiple threads will need to be serialized in some manner by the driver to preserve internal consistency.

A basic solution to thread safety is for the ODBC driver to serialize functions utilizing the same handle. That is, while a thread is executing an ODBC function on a handle, then all other threads attempting to execute an ODBC function on the same handle will be blocked (suspended) inside the function. When the thread utilizing the handle returns from the ODBC function, the handle is released for use by other threads. This solution is known as function-level thread safety.

Function-level thread safety places some of the burden on the application. This is because ODBC handles carry state information between calls to ODBC functions. For example:

A more ambitious ODBC driver might attempt to protect handle states across multiple functions. This is multi-function thread safety. Multi-function thread safety will increase shareability in some cases but reduce it in others.

A extreme example of reduced shareability would be if the ODBC driver protected the connected state of a connection handle. This protection would mean that when a given thread performs an ODBC connect on the handle, all other threads would be blocked from using the handle. The lock-out of other threads would continue until the original thread performed a disconnect. It would effectively prevent sharing of a connection handle.

An additional problem with multi-function thread safety is deadlock (deadly embrace). Application code can produce deadlock situations when using an ODBC driver providing multi-function thread safety. Deadlock can only be resolved by cancelling one of the threads. Drivers providing function-level thread safety can avoid deadlocks.

Given the problems with multi-function thread safety, it is not likely that ODBC drivers will provide this level of protection. If a driver provides thread-safe operation, it should use function-level thread safety. Applications should assume this.

Function-level thread safety does not protect state information stored in handles between function calls. Applications sharing the same handle between more than one thread will need to provide some amount of synchronization between threads. The second section, Synchronization, describes various portable methods of synchronizing threads.

Return to Contents Page: ODBC Thread Safety     Return to Issues Page


Copyright © 1998 FFE Software, Inc. All Rights Reserved WorldWide