Re: qpid (cpp) on solaris + Sun Studio 12

[Manuel Teira <mt...@tid.es>]

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
>
>
>
>