PreviousNext

Overview - Using Threads With The XDS/XOM API

Some programs work well when they are structured as multiple flows of control. Other programs may show better performance when they are multithreaded allowing the multiple threads to be mapped to multiple processors when they are available.

GDS application programs can contain multiple threads of control. For example, a GDS application can need to query several GDS servers. This can be achieved more efficiently by using separate threads simultaneously to query the different servers.

GDS supports multithreaded applications. Writing multithreaded applications over GDS imposes new requirements on programmers: they must manage the threads, synchronize threads' access to global resources, and make choices about thread scheduling and priorities.

This topic describes a simple GDS application that uses threads. (Refer to the *(3thr) reference pages for more information on DCE threads.)

The XDS/XOM API calls do not change when they are making use of DCE threads in an application program. The service underneath XDS/XOM API is designed to be both thread-safe, to allow multiple threads to safely access shared data, and cancel-safe, to handle unexpected cancellation of a thread in an application program.

The figure below shows an example of how an application can issue XDS/XOM calls from within different threads.


Issuing XDS/XOM Calls from within Different Threads

The order of thread completion is not defined; however, XDS/XOM has an inherent ordering. Multithreaded XDS applications must adhere to the following order of execution:

1. ds_initialize( )

2. ds_version( ) (optional)

3. ds_bind( )

4. Other XDS calls in sequence or parallel from multiple threads

5. ds_unbind( )

6. ds_shutdown( )

Multi-threaded XOM applications must adhere to the following order of execution:

1. ds_initialize( )

2. XOM calls in sequence or parallel from multiple threads

3. ds_shutdown( )

The XDS/XOM API will return an appropriate error code if these sequences are not adhered to. For example the following errors are returned:

DS_E_BUSY
If ds_unbind( ) is called while there are still outstanding operations, or if ds_shutdown( ) is called before all directory connections have been released by ds_unbind( ).

OM_NO_SUCH_WORKSPACE
If any XOM API calls are made before calling ds_initialize( ), or if a call to ds_shutdown( ) completes while there are outstanding XOM operations on the same workspace. In the latter case, these XOM operations will not be performed.