[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Apr 2018 11:35:55 -0400
From: Rich Felker <dalias@...c.org>
To: Patrick Oppenlander <patrick.oppenlander@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Some questions
On Mon, Apr 30, 2018 at 01:55:16PM +1000, Patrick Oppenlander wrote:
> On Mon, Apr 30, 2018 at 1:16 PM, Rich Felker <dalias@...c.org> wrote:
> > On Mon, Apr 30, 2018 at 12:52:06PM +1000, Patrick Oppenlander wrote:
> >> - Is there a way that spinlocks could be disabled or bypassed on
> >> uniprocessor systems?
> >
> > Whether locks are needed is a matter of whether there are multiple
> > threads, not whether it's uniprocessor or multiprocessor. For some
> > things where it's likely to matter (stdio, malloc, some other
> > internals), locks are already optimized out when there is only one
> > thread. In other cases it was deemed either too costly/difficult or
> > irrelevant to overall performance.
>
> I was talking about the case of a uniprocessor system running a multi
> theaded process.
>
> In that case the "spin" part of spinlock just burns time & electrons.
> The "lock" part obviously can't be omitted. Calling straight through
> to the kernel is the most efficient thing to do.
I see. Is this an issue you've actually hit? I don't see any obvious
way to make this decision at runtime that doesn't incur unwanted costs
or failure modes, and I suspect we're spinning way too many times
anyway even for SMP (i.e. the ideal solution might just be
significantly reducing the # of spins).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
