Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #673

Re: Locking primitives in userspace

From Steve Thompson <thomps2048@yahoo.ca>
Newsgroups comp.programming.threads
Subject Re: Locking primitives in userspace
Date 2011-11-10 09:42 -0500
Organization A poorly organized news site.
Message-ID <n8cpCe.LR7.q0AzR@invalid.invalid> (permalink)
References <ihU8Kn.Ndh.Tp3Zo@invalid.invalid> <yucDkT.qpT.kXcHb@invalid.invalid> <irgfb7p8pulflcaphbm88jta33sclru8vo@4ax.com>

Show all headers | View raw


On Mon, Nov 07, 2011 at 11:42:22AM +0000, Mark wrote:
> On Sun, 06 Nov 2011 06:54:37 -0500, Steve Thompson
> <thomps2048@yahoo.ca> 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

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Locking primitives in userspace Steve Thompson <thomps2048@yahoo.ca> - 2011-10-30 16:26 -0400
  Re: Locking primitives in userspace Steve Thompson <thomps2048@yahoo.ca> - 2011-11-06 06:54 -0500
    Re: Locking primitives in userspace Mark <i@dontgetlotsofspamanymore.invalid> - 2011-11-07 11:42 +0000
      Re: Locking primitives in userspace Steve Thompson <thomps2048@yahoo.ca> - 2011-11-10 09:42 -0500
  Re: Locking primitives in userspace Alexander Terekhov <terekhov@web.de> - 2011-11-08 08:30 +0100

csiph-web