Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Steve Thompson Newsgroups: comp.programming.threads Subject: Re: Locking primitives in userspace Date: Thu, 10 Nov 2011 09:42:24 -0500 Organization: A poorly organized news site. Lines: 48 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="CmXK45Z1EiIPM8u84qy55g"; logging-data="8498"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19AATf452xch77hAyRKc8d0" User-Agent: KNqde/0.10.9 Cancel-Lock: sha1:byluW2ZIooS7S3NDACLGzR4Qrf0= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:673 On Mon, Nov 07, 2011 at 11:42:22AM +0000, Mark wrote: > On Sun, 06 Nov 2011 06:54:37 -0500, Steve Thompson > wrote: > > >On Sun, Oct 30, 2011 at 04:26:05PM -0400, Steve Thompson wrote: > >> I've been writing some multi-threaded code and have some question > >> about userspace locking primitives and best practices. [snip] > Since no-one else has replied then I'll chip in. I'm not an academic > so am not really interested in examining obscure locking mechanisms. > However I would avoid such features and would stick to POSIX thread > features since my code has to be portable. I wouldn't say it is obscure, perhaps novel but no matter. I haven't examined the Linux kernel arch-specific code they use mostly because (a) it looks like macro-spaghetti, and (b) I've wanted to maintain a 'clean' development environment unpolluted by licence-restricted code. So far I can say that I've not reverse-engineered anything noteworthy, which ought to make my life easier down the road. Any IP collisions will be accidental or will arise subsequent to my design. As to portability, I have separated architecture-specific code from the program text to make porting trivial. I expect more problems as a consequence of using c99 features or GNUisms, or elsewhere due to differences in system call semantics. For your portability requirements you are relying on the system library writers to do the architecture-specific code for you, which is admittedly less work. My approach allows me to design the algorithm to my requirements rather than to the system library requirements. To be more concrete, at program startup, my code chooses a variant dependent upon the number of VCPUs present, meaning that there is no hard spinning in uniprocessor environments. You'll have to verify that your system libraries do the right thing for your target platform, if that is a concern in your development environment. > Sorry I can't offer any real help ;-) S'ok. Steve Thompson