On Sun, Nov 06, 2005 at 10:51:51AM -0800, Richard Henderson wrote: > I suppose that in some cases it would be possible to implement > them in libgcc. Certainly we provided for that possibility > by expanding to external calls.
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. The use of a mutex (or not) is part of the API associated with the memory location. If it's ever used by one part of the application, it must be used by all. The only thing we can do for libstdc++ is to put something in the config files that claims that atomic operations are *always* available for all members of the architecture family. If so, we may inline them. Otherwise, we should force the routines to be out-of-line in the library. This provides the stable ABI that we require. We may then use optimization flags to either implement the operation via atomic operations, or a mutex. We cannot provide fallbacks for the sync builtins in libgcc, because at that level we do not have enough information about the API required by the user. r~
