This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Call for compiler help/advice: atomic builtins for v3


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]