From: Alan Woodland (alan.woodland_at_gmail_dot_com)
Date: Mon Aug 24 2009 - 16:27:35 PDT
2009/8/24 Paul H. Hargrove <PHHargrove_at_lbl_dot_gov>: [snip] > There are at least 4 parts to the answer. > > 0) I'd be surprised if the SPARC architecture it usable, even if it > compiles. �It is documented to be incomplete and to support (IIRC) only > UltraSPARC and higher (see #2, below). > > 1) The gcc atomic builtins were not (widely?) available when we started this > project, and until recently we supported kernels as old as 2.4.0, which > required an ancient gcc-2.96. �If you were to implement an arch/generic in > the same spirit as the kernel's asm-generic I think we could use it when > support exists in the compiler, and as a porting aid, but we'd probably not > throw away the existing implementations. It looks like my initial reading of the atomic builtins was incorrect, and gcc generates the call to the external function if required, but not the function itself. This would still make porting to architectures with CAS a lot easier though. Testing at configure time the availability of atomic builtins is trivial and could then direct to either those or the existing implementations appropriately. For the replacement functions when it's not available some kind of 'cancelable' futex-based 'lock' shouldn't be impossible to construct, and then the atomic_cas replacement could handle cancellation sanely? > 2) Sparclite does not have the required atomic instructions. �With only a > test-and-set or load-and-clear type of atomic support one cannot implement a > signal-safe compare-and-swap in user space (kernel does it by blocking > interrupts momentarily). �This is true of "older" ARM as well, but on that > platform there is a neat kernel trick implemented by/for the NPTL port using > the equivalent of a VDSO to use the atomic instructions on "newer" ARM or > use the kernel for help otherwise. �I don't know of such a trick on > sparclite, but NPTL must work somehow. Which aspect of 'signalsafe' is problematic here? The async safe part? (I.e. if we get interrupted by a signal halfway through an atomic op we'd be holding a global lock and deadlock if we called another atomic op from the signal handler?) Which parts of the library actually need to be async safe? Is it just things which get called from the 'my_handler' functions in cr_cs.c and cr_async.c? (Also what's the problem in blocking signals whilst inside a replacement CAS function? Is it the unblockable signals?) > 3) Ever since we dropped 2.4.x kernel support, I have been wondering if we > could drop our user-space atomics entirely in favor of using futexes. > �However, I've not had the opportunity to examine that possibility. It sounds quite feasible. I'm not familiar enough yet with the internals to do it though. Q: Is there read only access to CVS available anywhere? The only mention of it other than reports on commits in bugzilla is in this email: http://www.nersc.gov/hypermail/checkpoint/0351.html Or are patches against 0.8.2 acceptable? Alan P.S. Is this list the right place for this discussion?