- * support locking by default. It is the callers responsibility to wrap
- * calls to functions like RAND_DRBG_generate() which modify the DRBGs
- * internal state with calls to RAND_DRBG_lock() and RAND_DRBG_unlock().
- * The functions RAND_bytes() and RAND_priv_bytes() take the locks
- * automatically, so using the RAND api is thread safe as before.
- *
- * All other DRBG instances don't have locking enabled by default, because
- * they are intendended to be used by a single thread. If it is desired,
- * locking can be enabled using RAND_DRBG_enable_locking(). However, instead
- * of accessing a single DRBG instance concurrently from different threads,
- * it is recommended to instantiate a separate DRBG instance per thread.
+ * support locking. The RAND methods take the locks automatically, so using
+ * the RAND api (in particular RAND_bytes() and RAND_priv_bytes()) is
+ * thread-safe. Note however that accessing the shared DRBGs directly via
+ * the RAND_DRBG interface is *not* thread-safe.
+ *
+ * All other DRBG instances don't support locking, because they are
+ * intendended to be used by a single thread. Instead of accessing a single
+ * DRBG instance concurrently from different threads, it is recommended to
+ * instantiate a separate DRBG instance per thread. Using the same shared
+ * DRBG (preferrably the public DRBG) as parent of DRBG instances on
+ * different threads is safe.