This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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] |
On 07/19/2016 02:03 PM, Anton Blanchard wrote:
Hi Florian.x86_64 checks __libc_multiple_threads and avoids atomics if possible. Do you already do this in POWER?x86 has CISCy instructions that do a local atomic increment/decrement, and I suspect they use that in the single threaded case. We do not have instructions like that on PowerPC, and it presents an issue for signals. I think we got resistance when we suggested using load/add/store instructions in single threaded mode on PowerPC because it made the async signal situation somewhat worse. Of course malloc is not defined to be async signal safe, and I bet there are places we fall apart today. Perhaps we can revisit this now we have an unlocked per thread cache in DJ's branch.
Yes, with the lockless, waitless cache, you get data corruption instead of a self-deadlock. :)
I think non-atomic updates are okay. I doubt that fork will be more broken than it is today. (fork is supposedly async-signal-safe, but our implementation is not because it touches the malloc locks.)
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |