OpenSSL can safely be used in multi-threaded applications provided
that at least two callback functions are set, locking_function and
threadid_func.

locking_function(int mode, int n, const char *file, int line) is
needed to perform locking on shared data structures.
(Note that OpenSSL uses a number of global data structures that
will be implicitly shared whenever multiple threads use OpenSSL.)
Multi-threaded applications will crash at random if it is not set.

locking_function() must be able to handle up to CRYPTO_num_locks()
different mutex locks. It sets the n-th lock if mode &
CRYPTO_LOCK, and releases it otherwise.

file and line are the file number of the function setting the
lock. They can be useful for debugging.

threadid_func(CRYPTO_THREADID *id) is needed to record the currently-executing
threads identifier into id. The implementation of this callback should not
fill in id directly, but should use CRYPTO_THREADID_set_numeric() if thread
IDs are numeric, or CRYPTO_THREADID_set_pointer() if they are pointer-based.
If the application does not register such a callback using
CRYPTO_THREADID_set_callback(), then a default implementation is used - on
Windows and BeOS this uses the systems default thread identifying APIs, and on
all other platforms it uses the address of errno. The latter is satisfactory
for thread-safety if and only if the platform has a thread-local error number
facility.

Once threadid_func() is registered, or if the built-in default implementation is
to be used;

o

CRYPTO_THREADID_current() records the currently-executing thread ID into the
given id object.

o

CRYPTO_THREADID_cmp() compares two thread IDs (returning zero for equality, ie.
the same semantics as memcmp()).

o

CRYPTO_THREADID_cpy() duplicates a thread ID value,

o

CRYPTO_THREADID_hash() returns a numeric value usable as a hash-table key. This
is usually the exact numeric or pointer-based thread ID used internally, however
this also handles the unusual case where pointers are larger than long
variables and the platforms thread IDs are pointer-based - in this case, mixing
is done to attempt to produce a unique numeric value even though it is not as
wide as the platforms true thread IDs.

Additionally, OpenSSL supports dynamic locks, and sometimes, some parts
of OpenSSL need it for better performance. To enable this, the following
is required:

dyn_destroy_function(CRYPTO_dynlock *l, const char *file, int line) is
needed to destroy the lock l. Multi-threaded applications might crash at
random if it is not set.

CRYPTO_get_new_dynlockid() is used to create locks. It will call
dyn_create_function for the actual creation.

CRYPTO_destroy_dynlockid() is used to destroy locks. It will call
dyn_destroy_function for the actual destruction.

CRYPTO_lock() is used to lock and unlock the locks. mode is a bitfield
describing what should be done with the lock. n is the number of the
lock as returned from CRYPTO_get_new_dynlockid(). mode can be combined
from the following values. These values are pairwise exclusive, with
undefined behaviour if misused (for example, CRYPTO_READ and CRYPTO_WRITE
should not be used together):

CRYPTO_set_locking_callback() is
available in all versions of SSLeay and OpenSSL.
CRYPTO_num_locks() was added in OpenSSL 0.9.4.
All functions dealing with dynamic locks were added in OpenSSL 0.9.5b-dev.
CRYPTO_THREADID and associated functions were introduced in OpenSSL 1.0.0
to replace (actually, deprecate) the previous CRYPTO_set_id_callback(),
CRYPTO_get_id_callback(), and CRYPTO_thread_id() functions which assumed
thread IDs to always be represented by unsigned long.