Le rand_s de Windows est-il thread-safe?

Question

Comme dans le titre. Est-ce suspect, mais je n'ai pu le trouver nulle part explicitement. Et pour cette propriété, je ne voudrais pas compter sur des spéculations.

Answer 1

Si vous utilisez la version multithread de CRT, toutes les fonctions sont thread-safe, car toutes les informations spécifiques aux threads sont stockées dans TLS . En réalité, rand_s n’utilise pas d’information d’état car il appelle simplement une API de système d’exploitation. La question de la sécurité des threads ne se pose donc pas pour rand_s. rand () dépend toutefois d’une valeur de départ pour générer un nombre aléatoire.

Answer 2

Chris a dit: rand () n'est pas thread-safe car son état interne est statique, mais rand_s () doit être thread-safe, cependant.

Jeff a toutefois ajouté qu'avec la version multithread de MSVCRT, l'état de rand () est conservé dans le stockage local des threads, donc tout va bien.

Answer 3

Visual Studio est fourni avec la source de la bibliothèque d'exécution. Rand_s () est assez simple, même s’il peut être assez pénible d’être parcouru.

Tous les rand_s () appellent SystemFunction036 () dans ADVAPI32.DLL pour obtenir la valeur aléatoire. Tout dans ADVAPI32.DLL doit être thread-safe.

De son côté, rand_s () obtient le pointeur sur cette fonction d'une manière thread-safe.

Answer 4

Je ne sais pas si rand_s est thread-safe, mais il semble que ce soit probablement le cas, car il semble effectuer un aller-retour vers l'OS pour l'entropie. (tant que vous vous connectez au CRT multi-thread VC ++, tous les paris sont désactivés si vous créez un lien vers celui à thread unique)

S'il est pris en charge par Windows CRT, vous pouvez essayer un appel à rand_r, qui est la version posix réentrante de rand. OU encore mieux boost :: random, si vous utilisez déjà boost.

Etant donné que le multi-threading va bientôt devenir omniprésent, personne ne devrait plus utiliser rand () dans son nouveau code - essayez toujours d'utiliser rand_r / rand_s / boost / divers rands sécurisés dépendants de la plate-forme / etc.

Answer 5

Je ne vois aucune raison pour laquelle rand_s () ou même rand () ne serait pas thread-safe.