On 11 September 2018 at 21:43, Emilio G. Cota <c...@braap.org> wrote: > On Tue, Sep 11, 2018 at 05:43:38 -0700, Richard Henderson wrote: >> Is this any better than using libatomic? > > I didn't think of using libatomic. I just checked the source > code and it's quite similar: > - It uses 64 locks instead of 16 ($page_size/$cache_line, > but these are hard-coded for POSIX as 4096/64, respectively) > - We compute the cacheline size and corresponding padding > at run-time, which is a little better than the above. > - The locks are implemented as pthread_mutex instead of > spinlocks. I think spinlocks make more sense here because > we do not expect huge contention (systems without > !CONFIG_ATOMIC64 have few cores); for libatomic it makes > sense to use mutexes because it might be used in many-core > machines. > > So yes, we could have used libatomic. If you feel strongly > about it, I can give it a shot.
I guess the question I have is: * will we need (now or in future) to emit atomic accesses into generated TCG code that need to interoperate with the atomic accesses we do from C code ? * if so, does libatomic provide a mechanism for doing that? (maybe there's nothing you can do except to call out from the generated code to C code anyway) thanks -- PMM