Al igual que en el título. Sospecho que lo es, pero no pude encontrarlo en ningún lugar explícitamente establecido. Y por esta propiedad no me gustaría confiar en las especulaciones.¿Es rand_s thread-safe de Windows?
Si utiliza la versión multithreaded del CRT, todas las funciones son seguras para hilos, porque cualquier información específica del hilo se almacena en TLS. rand_s en realidad no usa información de estado en primer lugar, ya que solo llama a una API de sistema operativo, por lo que la cuestión de seguridad de hilo no se plantea para rand_s. rand(), sin embargo, depende de un valor inicial para generar un número aleatorio.
No puedo pensar en ninguna razón por la cual rand_s() o incluso rand() no sean seguros para subprocesos.
Chris dijo: rand() no es seguro para subprocesos porque su estado interno es estático, pero rand_s() debe ser seguro para subprocesos, sin embargo.
Jeff agregó sin embargo que con la versión multihilo de MSVCRT, el estado de rand() se guarda en el almacenamiento local de subprocesos, por lo que todavía está bien.
De acuerdo con: http://hype-free.blogspot.com/2008/05/multi-threaded-visual-c-rand.html rand() almacena su estado en el TLS, lo que significa que es seguro para subprocesos del VC entorno (que está implícito en la pregunta específica sobre rand_s()). –
¡Gracias, Simucal y Jeff! –
Visual Studio viene con la fuente de la biblioteca en tiempo de ejecución. Mientras que algunos de ellos pueden ser bastante dolorosos, rand_s() es bastante simple.
Todo lo que hace rand_s() es llamar a SystemFunction036() en ADVAPI32.DLL para obtener el valor aleatorio. Cualquier cosa en ADVAPI32.DLL debería ser seguro para subprocesos.
Por su parte, rand_s() obtiene el puntero a esa función de forma segura para la ejecución de subprocesos.
No sé si rand_s es seguro para subprocesos, pero parece que probablemente lo sea, ya que parece que hace una ida y vuelta al sistema operativo para la entropía. (siempre y cuando se vincule con el CRT multihilo de VC++, todas las apuestas estarán desactivadas si enlaza con el hilo único)
Si es compatible con CRT de Windows, puede intentar una llamada a rand_r que es la posix versión reentrante de rand. O incluso mejor impulso :: al azar, si ya estás usando boost.
teniendo en cuenta lo penetrante que será el multihilo pronto, nadie debería estar usando rand() en el nuevo código - siempre intente usar rand_r/rand_s/boost/varios rands seguros dependientes de la plataforma/etc.
De acuerdo, pero sigue siendo una especulación. Por ejemplo, rand() almacena su semilla actual en una variable compartida por todos los hilos ... Y en POSIX hay funciones especiales que están diseñadas para su uso dentro de los hilos. –
rand() no es seguro para subprocesos, porque su estado interno estático, como phjr mencionado. rand_s() debería ser seguro para subprocesos, sin embargo. –
publicó su comentario como respuesta de la comunidad chris – mmcdole