incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <nikko...@hates.ms>
Subject Re: STDCXX-1066 [was: Re: STDCXX forks]
Date Sun, 23 Sep 2012 23:25:11 GMT
On 9/23/12 6:47 PM, Stefan Teleman wrote:
> On Sun, Sep 23, 2012 at 6:19 PM, Liviu Nicoara <nikkoara@hates.ms> wrote:
>> On 9/23/12 5:23 PM, Stefan Teleman wrote:
>>>
>>> On Sun, Sep 23, 2012 at 4:58 PM, Liviu Nicoara <nikkoara@hates.ms> wrote:
>>>
>>>> Stefan, I stumbled upon this: http://tinyurl.com/ceet6ec and this:
>>>> http://tinyurl.com/c4h9mgl
>>>
>>>
>>> The first URL is Fujitsu. It doesn't mention anything about the
>>> side-effects of KU-137111. It's just a description on how to apply
>>> kernel patches.
>>
>>
>> Hold on. If you go in the bottom half of that page you will see:
>>
>> *2) The following shows an example of programming that causes the
>>            above problem.
>>
>>          <In the case where the problem occurs>
>>            ----------------------------------------------------------------
>>            int       *ip;
>>            mutex_t   *mp;
>>            ip = (int *) malloc(sizeof (int) + sizeof (mutex_t));
>>            mp = (mutex_t *) (ip + 1);
>>                               /* The address is used with a modification */
>>            ----------------------------------------------------------------
>>
>>          <In the case where the problem does not occur -1>
>>            ----------------------------------------------------------------
>>            mutex_t   mp;                          /* Obtained statically */
>>            ----------------------------------------------------------------
>>
>>          <In the case where the problem does not occur -2>
>>            ----------------------------------------------------------------
>>            mutex_t   *mp;
>>            mp = (mutex_t *) malloc(sizeof (mutex_t));
>>                         /* The address is used without any modifications */
>>            ----------------------------------------------------------------
>
> First of all, this is C. And it's using the mutex_t Solaris type directly.
>
> We're in C++, where the pthread_mutex_t type is a data member of a
> class.

You're saying that the alignment of objects of type S:

struct S {
     pthread_mutex_t mutex_;
};

can be less strict than the alignment of the pthread_mutex_t member? Say, for 
this example:

int main () {
     S s;
     printf ("%p\n", &s);
}

I could see an address that is not a multiple of 8? What does it print on your 
SPARC V8 machine?

> In some cases it's a pointer (such as __rw_guard).

The alignment of a pthread_mutex_t* object has no bearing on the alignment of 
the pthread_mutex_t object it points to. Why would you align the pointer to an 
object to the alignment requirements for the actual object?

> In some other cases it's part of a derived type.

Could you please give us a small example where the alignment of a mutex member 
in a sub-object of a derived-type object is not a multiple of 8?

>
>> I am not saying I don't believe you. But you have to give us something more
>> than "trust me, I know what I'm doing". You have to admit that the patch
>> looks funny, e.g., in that it does not follow the published documentation
>> for Solaris Studio 12.3.
>
> It doesn't look funny to me. It looks like it's working.
>
> Exactly what is it that I should give you, other than a tested,
> working, already in production patch? A different implementation which
> doesn't "look funny"?

I am not asking for any other implementation and I am not looking to change 
anything. I wish you could explain it to us, but in the absence of trade secret 
details I will take an explanation for the questions above.

Thanks!

Liviu


Mime
View raw message