Next: , Previous: , Up: Introduction to the library   [Contents][Index]


6.1.5 Thread safety

The GnuTLS library is thread safe by design, meaning that objects of the library such as TLS sessions, can be safely divided across threads as long as a single thread accesses a single object. This is sufficient to support a server which handles several sessions per thread. If, however, an object needs to be shared across threads then access must be protected with a mutex. Read-only access to objects, for example the credentials holding structures, is also thread-safe.

A gnutls_session_t object can be shared by two threads, one sending, the other receiving. In that case rehandshakes, if required, must only be handled by a single thread being active. The termination of a session should be handled, either by a single thread being active, or by the sender thread using gnutls_bye with GNUTLS_SHUT_WR and the receiving thread waiting for a return value of zero.

The random generator of the cryptographic back-end, utilizes mutex locks (e.g., pthreads on GNU/Linux and CriticalSection on Windows) which are setup by GnuTLS on library initialization. Prior to version 3.3.0 they were setup by calling gnutls_global_init.17 Note that, on Glibc systems the GnuTLS library does not link with the libpthread library by default, it utilizes the Glibc mutex stubs, which allows Glibc to use the non-multithreaded (and optimized) variants of its algorithms. That, however, for applications using GnuTLS that may potentially utilize mutexes, requires them to explicitly link with libpthread.


Footnotes

(17)

On special systems you could manually specify the locking system using the function gnutls_global_set_mutex before calling any other GnuTLS function. Setting mutexes manually is not recommended.