Re: pthread mutex and data alignment Nicholas Dronen wrote:
> T.R.Bennett <bennett.tony@cnf.com> wrote:
> TRB> Has anyone had data alignment problems when using
> TRB> pthreads while compiling a program with the
> TRB> "-qalign=packed" directive ????
Sounds like the system include files should incorporate
wrappers that undo any alignment chosen by the user...
> TRB> Our specific problem was in a pthread_mutex_trylock() call
> TRB> ....it incorrectly reports the mutex is locked...
> TRB> unless we force the pthread_mutex_t onto a full-word alignment...
> TRB> ...then it works correctly.
>
> Whose problem it is depends on whether the mistake happens in the
> code (bad assumptions, bad data or variable access methods, whatnot)
> or the compiler (invalid behavior for pragma). You don't say under
> what exact circumstances the problem occurs. Do you have a small
> testcase that you can use to debug the problem outside of your
> application? If so, you have a chance to gather some information
> that might be useful for you or the vendor.
>
> And if the behavior disappears when you wrap your pthread code in
> '#pragma options align=reset', you're one step closer to knowing
> who to blame. :-)
It would probably make more sense to "stack" the pragma for
system structures, then "pop" back to the prior behavior.
> Small testcase. Try using 'reset'. Post what happens. Gary Hook,
> AKA Superfly of Linking, will respond. Eventually all will be well.
> (And Gary works for free. How much better can it get? :-)
Yeah, but I'm setting up a 1-900 number :-)
The packing pragma would nominally be applied to all of the code.
Unfortunately, certain system structures are going to have be
left alone. In this case, a lock had better be word aligned;
there are no options, no choices, no changes. Perhaps you
only need to wrap your structure definitions in the pack
pragma; the compiler should understand how to access the
members in that case, but that would leave the rest of the
system code alone.
--
Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE
__________________________________________________ ______________________ |