Kay Röpke wrote: > > On Mar 9, 2009, at 12:28 AM, Monty Taylor wrote: > >>> it strikes me as odd, considering that most, if not all, modern >>> operating systems ship this kind of thing in libc. i might be missing >>> something, though (and am genuinely interested in what that might be, >>> since i'm working on lock-free data structures right now). >>> however, if the goal is to save you the ld stub call to libc and >>> inlining the assembly required, i can see the point. >> >> It's not that implementations aren't all over the place (and I certainly >> don't mind link steps) - the real problem is finding standard interfaces >> for this stuff. >> >> GCC atomics was a nice stop gap for dealing with that for us... except >> it still isn't a win because we can't use GCC on Solaris. So what I >> wound up doing is making a local impl of atomic<> for when one isn't >> there already and filling in the impl with gcc atomics if we're on GCC >> and atomic.h if we're on solaris. If all of the above fails, with >> pthread locks. (eek) >> >> If I'd known about 4.2 on OSX, I wouldn't have had to write the >> pthread-lock implementation, since GCC4.0 on OSX was the only one that >> wasn't covered by existing interfaces to system atomic behavior. In fact >> ... I might be able to delete it now... > > for reference: OS X has <libkern/OSAtomic.h> (don't be fooled by the > libkern in there, it's part of libc) > but yeah, if gcc implements them already, that's easier. wonder if > LLVM/gcc does the right thing and pulls them from gcc.
I need to take a look at LLVM... > we are using glib's implementation right now, since i seriously don't > want to go hunting for this stuff on AIX and HP/UX, > plus it swaps in the pthread version if it has to punt. rather > convenient. you might want to take a look at that (gatomic.[ch] in glib2). I'll take a look at it... although I'm pretty pleased with the atomic<> stuff... the interface is very nice and natural - plus it's involved in the definition of the var: atomic<uint32_t> my_counter; so you can't not interface it atomically and then subvert the pthread-fallback or anything. I got shot down for wanting to use some glib stuff early on (funny enough, because there was a complaint that installing glib on OSX was too much :) ) I'm dying to replace all the getopt stuff with the glib getopt replacement... >> These will pretty much be useful for decent interface to things like >> counters and the like, I think... still working on it though. > > > under the covers it all boils down to a few primitives anyway, so either > API is fine with me :) Indeed. I love how much trouble we go through to get at them consistently. Monty _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
