Date: Sun, 17 May 2015 12:28:54 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Deduplicating atomics written in terms of CAS On Sun, May 17, 2015 at 09:37:19AM +0200, Jens Gustedt wrote: > Am Sonntag, den 17.05.2015, 02:14 -0400 schrieb Rich Felker: > > - a_and_64/a_or_64 (malloc only; these are misnamed too) > > I should have checked the use before my last mail. They are > definitively misnamed. > > Both uses of them look ok concerning atomicity, only one of the a_and > or a_or calls triggers. > > The only object (mal.binmap) to which this is applied is in fact > volatile, so it must actually be reloaded all the time it is used. > > But in line 352 the code uses another assumption, then, that 64 bit > loads always are atomic. I don't see why this should hold in general. I don't think there's such an assumption. The only assumption is that each bit is read exactly the number of times it would be on the abstract machine, so that we can't observe inconsistent values for the same object. Lack of any heavy synchronization around reading the mask may result in failure to see some changes or seeing them out of order, but it doesn't matter: If a bin is wrongly seen as non-empty, locking and attempting to unbin from it will fail. If it is wrongly seen as empty, the worst that can happen is a less-optimal (but would have been optimal an instant earlier) larger chunk gets split instead of using a smaller one to satisfy the allocation. Of course it's an open question whether the complex atomics and fine-grained locking in malloc help or hurt performance more on average. I'd really like to measure this at some point. Overhauling malloc to try to get significantly better multi-threaded performance without the fragmentation-optimality sacrifices other mallocs make is a long-term goal I have open. > We already have a similar assumption for 32 bit int all over the > place, and I am not too happy with such "silent" assumption. For 64 > bit, this assumption looks wrong to me. I agree I wouldn't be happy with such an assumption, but I don't think it's being made here. > I would be much happier by using explicit atomic types and atomic load > functions or macros everywhere. For normal builds these could be dummy > types made to resolve to the actual code that we have, now. But this > would allow to have hardening builds, that check for consistency of > all atomic accesses. There is no way to do an atomic 64-bit load on most of the archs we support. So trying to make it explicit wouldn't help. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.