Although the SOM kernel and the other SOMobjects frameworks allow applications to be multi-threaded, the kernel and frameworks generally do not require or exploit threads themselves. But there are some exceptions: for example, application servers in DSOM can be configured so that each incoming request is executed on a separate thread.
An application may choose to employ "native" multi-threading services provided by the underlying operating system (for example, OS/2). On other operating systems that do not support native multi-threading (such as, AIX 3.2), thread support may be provided as part of particular programming environments (like DCE) or libraries. SOM provides a mechanism that allows an application to define and customize the multi-threading services used by SOMobjects frameworks.
Four thread service functions are defined for use by SOMobjects frameworks. These functions may be called indirectly via the global pointer variables defined below. A somToken parameter (called "thrd" below) is used as a generic "handle" to refer to a thread # usually it is a pointer to a thread id or descriptor. The actual representation of the thread handle is hidden by the functions.
typedef void somTD_SOMThreadProc(void * data);
unsigned long (*SOMStartThread)(somToken *thrd,
somTD_SOMThreadProc proc,
void *data,
unsigned long datasz,
unsigned long stacksz);
The referenced function starts a thread, and returns a thread handle in the somToken variable identified by "thrd". The thread executes the procedure whose address is specified by the proc parameter; the thread procedure takes a single void* argument and returns void. The data parameter passed to SOMStartThread is passed on to the thread procedure; the size of the data parameter, in bytes, is given by datasz. A stack of stacksz bytes will be allocated for the thread.
Note: On OS/2, the thread procedure must be compiled with _Optlink linkage.)
If the call succeeds, a 0 is returned. Otherwise, a non-zero error code is returned.
unsigned long (*SOMEndThread)(void);
The referenced function terminates the calling thread.
If the call succeeds, a 0 is returned. Otherwise, a non-zero error code is returned.
unsigned long (*SOMKillThread)(somToken thrd);
The referenced function terminates the thread identified by the input parameter thrd.
If the call succeeds, a 0 is returned. Otherwise, a non-zero error code is returned.
unsigned long (*SOMGetThreadHandle)(somToken * thrd);
The referenced function returns a handle that can be used to identify the calling thread. The handle is returned in the somToken variable pointed to by thrd.
If the call succeeds, a 0 is returned. Otherwise, a non-zero error code is returned.
The actual mutex service function prototypes and global variable declarations are found in file "somthrd.h".
If the underlying operating system supports native multi-threading (currently, only OS/2), SOM provides appropriate default multi-threading service function implementations. On those operating systems that do not support native multi-threading, the default multi-threading service functions have null implementations.
An application may want to use threading services different from those provided by the underlying operating system (if any); for example, DCE applications will want to use DCE threads. In that case, the default multi-threading service functions can be replaced by application#defined functions.
An application program would use code similar to the following to install the replacement routines:
#include <somthrd.h>/* Define a replacement routine: */
unsigned long myStartThread (somToken *thrd,
somTD_SOMThreadProc proc,
void *data,
unsigned long datasz,
unsigned long stacksz)
{
(Customized code goes here)
}
...
SOMStartThread =myStartThread;
It is important to install custom multi-threading service functions before any SOM calls are made.