"Fossies" - the Fresh Open Source Software Archive

Member "openssl-1.1.1b/doc/man3/CRYPTO_THREAD_run_once.pod" (26 Feb 2019, 4775 Bytes) of package /linux/misc/openssl-1.1.1b.tar.gz:

Caution: As a special service "Fossies" has tried to format the requested pod source page into HTML format but links to other pod pages may be missing or even errorneous. Alternatively you can here view or download the uninterpreted pod source code. A member file download can also be achieved by clicking within a package contents listing on the according byte size field. See also the last Fossies "Diffs" side-by-side code changes report for "CRYPTO_THREAD_run_once.pod": 1.1.1-pre8_vs_1.1.1-pre9.


CRYPTO_THREAD_run_once, CRYPTO_THREAD_lock_new, CRYPTO_THREAD_read_lock, CRYPTO_THREAD_write_lock, CRYPTO_THREAD_unlock, CRYPTO_THREAD_lock_free, CRYPTO_atomic_add - OpenSSL thread support


 #include <openssl/crypto.h>

 int CRYPTO_THREAD_run_once(CRYPTO_ONCE *once, void (*init)(void));

 int CRYPTO_THREAD_read_lock(CRYPTO_RWLOCK *lock);
 int CRYPTO_THREAD_write_lock(CRYPTO_RWLOCK *lock);
 void CRYPTO_THREAD_lock_free(CRYPTO_RWLOCK *lock);

 int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK *lock);


OpenSSL can be safely used in multi-threaded applications provided that support for the underlying OS threading API is built-in. Currently, OpenSSL supports the pthread and Windows APIs. OpenSSL can also be built without any multi-threading support, for example on platforms that don't provide any threading support or that provide a threading API that is not yet supported by OpenSSL.

The following multi-threading function are provided:


CRYPTO_THREAD_run_once() returns 1 on success, or 0 on error.

CRYPTO_THREAD_lock_new() returns the allocated lock, or NULL on error.

CRYPTO_THREAD_lock_free() returns no value.

The other functions return 1 on success, or 0 on error.


On Windows platforms the CRYPTO_THREAD_* types and functions in the openssl/crypto.h header are dependent on some of the types customarily made available by including windows.h. The application developer is likely to require control over when the latter is included, commonly as one of the first included headers. Therefore it is defined as an application developer's responsibility to include windows.h prior to crypto.h where use of CRYPTO_THREAD_* types and functions is required.


This example safely initializes and uses a lock.

 #ifdef _WIN32
 # include <windows.h>
 #include <openssl/crypto.h>

 static CRYPTO_RWLOCK *lock;

 static void myinit(void)
     lock = CRYPTO_THREAD_lock_new();

 static int mylock(void)
     if (!CRYPTO_THREAD_run_once(&once, void init) || lock == NULL)
         return 0;
     return CRYPTO_THREAD_write_lock(lock);

 static int myunlock(void)
     return CRYPTO_THREAD_unlock(lock);

 int serialized(void)
     int ret = 0;

     if (mylock()) {
         /* Your code here, do not return without releasing the lock! */
         ret = ... ;
     return ret;

Finalization of locks is an advanced topic, not covered in this example. This can only be done at process exit or when a dynamically loaded library is no longer in use and is unloaded. The simplest solution is to just "leak" the lock in applications and not repeatedly load/unload shared libraries that allocate locks.


You can find out if OpenSSL was configured with thread support:

 #include <openssl/opensslconf.h>
 #if defined(OPENSSL_THREADS)
     /* thread support enabled */
     /* no thread support */




Copyright 2000-2018 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the OpenSSL license (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at https://www.openssl.org/source/license.html.