libstdc++/7926

[Phil Edwards]

On Mon, Nov 04, 2002 at 09:10:27PM -0600, Loren James Rittle wrote:
> It breaks
> multi-threading on i386-unknown-freebsd[45] when the processor is
> really something greater than an i386.  This is not uncommon since
> FreeBSD, unlike Linux, always reports i386 via uname instead of a
> dynamically-computed answer based on the CPU.

Some Linux distros specify i386 as the target when configuring, for maximal
portability, so FreeBSD isn't alone there.


> However, I know already that this patch will cause much pain if ever
> unleashed upon users in its current form.

I was/am expecting that generic/atomicity.h would be fixed to use gthr.h's
mutexes before 3.2.1 is shipped...


> Next point, even after considering the instruction that is not
> available on i386 (I am not responsible for the current state of that
> file and this was news to me), that file is closer to correct than
> using plain generic since it uses a proper LOCK adornment (which was
> legal on i386).  We now know it doesn't exist natively but the open
> question is an atomic exchange and add operation constructible for
> i386?  I don't know the answer but it seems reasonable to look for an
> answer rather than just blow away the file as if it never existed.

...even if we can't find a native answer for i386.


> On the PPC, an asm back-off loop had to be constructed to properly
> implement this feature.  Why can't this be done here?

*shrug*  I don't know enough about the i386 to speak.


> static inline _Atomic_word 
> __attribute__ ((__unused__))
> __exchange_and_add (volatile _Atomic_word *__mem, int __val)
> {
>   register _Atomic_word __proposed_result;
>   register _Atomic_word __proposed_new;
>   do {
>     __proposed_result = *__mem;
>     __proposed_new = __proposed_result + __val;
>   } while (!__atomic_cmpset (__mem, __proposed_result, __proposed_new));
> 
>   return __proposed_result;
> }

Nice.  I wonder whether we could use that in generic somehow.  Hmmm.  I'll
sleep on that one.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002