On Sat, Jul 30, 2011 at 2:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Portability, or rather lack of it. What about using erand48, which we
>>> already have a dependency on (and substitute code for)?
>
>> Neither our implementation nor glibc's appears to be thread-safe,
>
> I think you're confusing srand48 with erand48. The latter relies on a
> caller-supplied state value, so if it's not thread-safe the caller has
> only itself to blame.
I may be confused, but I'm not mixing it up with srand48. On my
Fedora 12 VM, the man page says for erand48_r says, in relevant part:
SYNOPSIS
#include <stdlib.h>
int erand48_r(unsigned short xsubi[3],
struct drand48_data *buffer, double *result);
DESCRIPTION
These functions are the reentrant analogs of the functions described in
drand48(3). Instead of modifying the global random generator state,
they use the supplied data buffer.
And the glibc implementation of erand48 is this:
double
erand48 (xsubi)
unsigned short int xsubi[3];
{
double result;
(void) __erand48_r (xsubi, &__libc_drand48_data, &result);
return result;
}
On second look, I think our version is probably safe in this regard
since it appears modify only the state passed in and not anything
else.
*pokes a little more*
If I'm reading the code right, it only modifies __libc_drand48_data on
first call, so as long as we called erand48() at least once before
spawning the child threads, it would probably work. That seems pretty
fragile in the face of the fact that they explicitly state that
they're modifying the global random generator state and that you
should use erand48_r() if you want reentrant behavior. So I think if
we're going to go the erand48() route we probably ought to force
pgbench to always use our version rather than any OS-supplied version.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
