On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Richard Henderson wrote: > > >Actually, no, it's not possible. At least in the context we're > >discussing here. Consider: > > > >One part of the application (say, libstdc++) is compiled with only > >i386 support. Here we wind up relying on a mutex to protect the > >memory update. Another part of the application (say, the exe) is > >compiled with i686 support, and so chooses to use atomic operations. > >The application will now fail because not all updates to the memory > >location are protected by the mutex. > > > > > Richard, sorry, I don't agree, on second thought. You are not > considering that the idea is using a "smart" libgcc, a la glibc, as per > Mark and Uli messages. > > A "libstdc++ compiled with only i386 support" what is it? It is a > libstdc++ which at run time will call into libgcc, it has nothing > inline. Then libgcc will use the best the machine has available, that > is, certainly atomic operations, if the exe (compiled with -march=i686) > can possibly run. > > In short, the keys are: > 1- The "smart" libgcc, which always makes available the best the machine. > 2- Mutexes cannot be inline, only atomic operations can.
Richard is right - it's enough that the inlined version doesn't agree with whatever smartness is in libgcc. But I also don't understand Richards suggestion -- it basically means you decide at libstdc++ compile-time, whether you can run on i386 or not. This is of course ok for 99.99% of all cases (distribution vendors supporting only i486+ anyway), but still does not support changing the decision at application compile-time. Note that in this particular case of atomic operations I can care less about i386... ;) Richard.
