Andrew Stitcher escribió:
On Fri, 2008-05-30 at 09:33 -0400, Alan Conway wrote:
Manuel Teira wrote:
[snip]
So, shouldn't we use different pthread_once_t variables for each of the
initializers?
Absolutely, well spotted!
Even more interesting, how can this work on linux, for example?
I'd hazard a guess that on linux both attributes start off with all-0 values,
all-0 is is the correct value for one of the two attributes, and by sheer dumb
luck things are declared/linked in such an order that it's the other attribute
that gets initialized first under the once_control.
Actually a better question is why RW locks are initialised like this in
the first place.
Good observation, initializing with a default pthread_rwlockattr_t
attribute is the same than using a NULL argument.
So, I'm going to open a bug and change the patch to avoid all this
machinery for the RWlock.
From the pthread_rwlock_init man page:
The pthread_rwlock_init() function initializes the read-
write lock referenced by rwlock with the attributes refer-
enced by attr. If attr is NULL, the default read-write
lock attributes are used; the effect is the same as passing
the address of a default read-write lock attributes object.
Thanks and best regards.
--
Manuel.
As RW locks don't need to set any initial attributes you don't need the
whole initialisation machinery for them. It's only there because we
needed recursive locks for the standard mutex.
I think there might have been a little bit of unthinking copy and paste
going on here.
Of course we should also be trying to eliminate all need for recursive
locks as a design thing, but at least under Linux they aren't much less
efficient than non recursive ones.
Andrew
