Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #83999

std::random_device and multithreading

From Andrey Tarasevich <andreytarasevich@hotmail.com>
Newsgroups comp.lang.c++
Subject std::random_device and multithreading
Date 2022-05-09 08:28 -0700
Organization A noiseless patient Spider
Message-ID <t5bbv1$gp2$1@dont-email.me> (permalink)

Show all headers | View raw


Hello

There are quite a few questions on the Net about using `<random>` in 
multithreaded environment, but virtually everything I find talks about 
sharing `std::random_device`, `std::mt19937`, etc. objects between threads.

My question is different. Let's say we are *not* sharing these objects 
at all. Let's say we are running multiple thread functions, each of 
which declares its own `std::random_device` locally and using the 
device's `()` operator

   void thread_function()
   {
     std::random_device rd;
     ...
     auto r = rd(); // ???
     ...
   }

Looks fine at the first sight. However, `std::random_device`s 
specification implies that it can be based on a shared global resource, 
like a hardware source of randomness or some other shared entropy pool, 
whose hardware/software nature is opaque to us.

So, if it does use a shared resource, does the standard give us a 
guarantee that polling automatic (as in the example above) or 
`thread_local` objects of `std::random_device` type is thread-safe?

I mean, to me it is virtually obvious that such guarantee should exist. 
Otherwise, I'd be weird, to put it mildly. But perhaps someone can quite 
the relevant portion of the spec...

-- 
Best regards,
Andrey

Back to comp.lang.c++ | Previous | NextNext in thread | Find similar | Unroll thread


Thread

std::random_device and multithreading Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-09 08:28 -0700
  Re: std::random_device and multithreading Juha Nieminen <nospam@thanks.invalid> - 2022-05-10 05:16 +0000
    Re: std::random_device and multithreading Juha Nieminen <nospam@thanks.invalid> - 2022-05-10 05:19 +0000

csiph-web