Comments on: Wanted: a portable mutex and atomic refcount http://blog.reverberate.org/2009/08/14/wanted-a-portable-mutex-and-atomic-refcount/ parsing, performance, minimalism with C99 Mon, 06 Feb 2012 23:44:51 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Dave http://blog.reverberate.org/2009/08/14/wanted-a-portable-mutex-and-atomic-refcount/comment-page-1/#comment-1436 Dave Mon, 17 Aug 2009 22:28:33 +0000 http://blog.reverberate.org/?p=275#comment-1436 One of my projects, the Open Portable Atomics (or sometimes OpenPA or OPA) would probably fulfill at least half of your requirements. We support a half-dozen or so (depending on how you count it) architectures right now with plans to add more incrementally. We would also welcome contributions if you have a platform that you need it to work on. The license is very permissive, basically MIT-style, do whatever you want with it. https://trac.mcs.anl.gov/projects/openpa/ It of course provides _more_ functionality than you need, but not excessively so. So you might count it out on the basis of "not tiny enough for Josh's taste" ;) It definitely doesn't live in one header file, we typically use one header for each platform. At the very least you could use it as the starting point for your crazy minimalist implementation, since writing this sort of thing is *very* error prone. One of the goals for the library is simplicity of use, which means that we made design decisions to minimize the amount of feature testing that you need to do as the consumer of the API. This is in stark contrast to the libatomic_ops project which attempts to provide atomics for most/all fixed width types on the platform in full combination with the various memory barrier types (last time I looked at it, anyway). Do you really want it to compile to nothing if you specify NO_THREAD_SAFETY or do you want thread-unsafe operations to occur instead? I can see use cases for both, although probably the thread-unsafe version is what you want in most cases. We have a layer in MPICH2 that wraps pthreads, windows, and solaris mutex APIs, although it is extremely ugly and there's no way that you would be able to sensibly disentangle it from the library (that's all legacy code that I didn't write). That's something that would probably be worth implementing in OPA some day, although I doubt I'll get around to it any time soon. Getting into the business of wrapping the threading library is a whole separate can of portability worms than writing atomic assembly inlines. Mail me if you want more detailed info about OPA. One of my projects, the Open Portable Atomics (or sometimes OpenPA or OPA) would probably fulfill at least half of your requirements. We support a half-dozen or so (depending on how you count it) architectures right now with plans to add more incrementally. We would also welcome contributions if you have a platform that you need it to work on. The license is very permissive, basically MIT-style, do whatever you want with it.

https://trac.mcs.anl.gov/projects/openpa/

It of course provides _more_ functionality than you need, but not excessively so. So you might count it out on the basis of “not tiny enough for Josh’s taste” ;) It definitely doesn’t live in one header file, we typically use one header for each platform. At the very least you could use it as the starting point for your crazy minimalist implementation, since writing this sort of thing is *very* error prone.

One of the goals for the library is simplicity of use, which means that we made design decisions to minimize the amount of feature testing that you need to do as the consumer of the API. This is in stark contrast to the libatomic_ops project which attempts to provide atomics for most/all fixed width types on the platform in full combination with the various memory barrier types (last time I looked at it, anyway).

Do you really want it to compile to nothing if you specify NO_THREAD_SAFETY or do you want thread-unsafe operations to occur instead? I can see use cases for both, although probably the thread-unsafe version is what you want in most cases.

We have a layer in MPICH2 that wraps pthreads, windows, and solaris mutex APIs, although it is extremely ugly and there’s no way that you would be able to sensibly disentangle it from the library (that’s all legacy code that I didn’t write). That’s something that would probably be worth implementing in OPA some day, although I doubt I’ll get around to it any time soon. Getting into the business of wrapping the threading library is a whole separate can of portability worms than writing atomic assembly inlines.

Mail me if you want more detailed info about OPA.

]]>