ASAP 1.1 Hybrid Manual

HP NonStop ASAP Hybrid Manual – 529729-004
Page 4-6
made to tailor the API to the Linux environment. For example, procedure names
are slightly different in order to follow standard Linux practices, in some cases the
number or types of parameters have changed slightly, and in every case the
range of returned values varies from the range used in ASAPX because the error
scenarios on Linux differ widely from those on the NonStop server. However, the
general purpose of each procedure has not changed, and there is a one-to-one
relationship between ASAPX API procedures and ASAP Hybrid for Linux API
procedures.
For details on the differences between the Linux and NonStop versions of each
procedure, see the description of that procedure in the API Details section.
Threading
To support both single-threaded and multithreaded client applications, two
procedures are frequently supplied for a given purpose: a standard version and a
thread-safe version. The thread-safe version is named the same as the standard
version, with ts appended to the name. For example, asap_update is a standard
call, and asap_update_ts is the thread-safe variant.
The main difference between the standard version of a call and the thread-safe
version of a call is that the thread-safe version automatically protects access to
shared counter space via a Pthreads mutex. Multiple threads can attempt to
update the same metrics simultaneously, and the ASAP Hybrid library ensures
that such updates are serialized.
In general, you should use the thread-safe procedures only if you are truly
sharing ASAP data items between threads., The thread-safe variants can
introduce some blocking into call processing while waiting for a mutex to free
and also incur extra system overhead in order to utilize the mutex.
Note: There is no risk of deadlock in using the thread-safe API procedures.
Because the ASAP Hybrid library manages all mutex access, any mutex-related
resources are freed by the time the ASAP API procedure returns control to the
calling thread. Furthermore, the API procedures themselves never own or wait on
more than one resource at a time. There is no opportunity for the thread or the
ASAP API to deadlock while waiting for an ASAP-related resource.