Date: Fri, 15 Dec 2000 08:26:24 -0800 From: Julian Elischer <julian@elischer.org> To: Chuck Paterson <cp@bsdi.com> Cc: smp@FreeBSD.ORG Subject: Re: atomic increment? Message-ID: <3A3A4630.1905D5D@elischer.org> References: <200012151408.eBFE8PF44272@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chuck Paterson wrote:
>
> Julian,
>
> This is not an argument against, or for, your request.
>
> I am sure I am starting to sound like a broken record,
> but so be it.
Yes you are..
>
> Please remember that atomic ops are really expensive, at
> least as expensive as acquiring a mutex.
That depends on what you wnat to do with them!
If I wnat nothing but to write a 1 to a location, and know at teh same
time whether the previous contents was a 1 or a 0 then most machines
allow that to be done pretty cheaply (2 memory cycles - overlap)
A full blown mutex is at least that.. (at a minimum).
I'm interested in adding locks to netgraph. If you are trying to bridge two
100Mb ethernets using netgraph, that's up to 300,000 node transitions
per second (in each direction if it's full duplex).
I DO NOT want to have people complaining that netgraph is too slow
because I have to to 600,000 mtx_enters 600,000 mtx_exit's
every second. And on top of that if there is a colision, I have to
queue the packet on a queue that is guarded in some way, so it's probably closer
to
800,000 per second. (don;t mention Gb ethernet)
I have the reader/writer locks written and I can use mtx_enter
and mtx_exit to make them work, but that's plain disgusting.
The reader/writer locks are PEERS of the current mutexes.
They should not be clients of them.
(see below)
> In some cases, of which
> X86 is not one, they are more expensive than just acquiring the
> mutex. Typically they are cheaper than acquiring and releasing a
> mutex, in the case of X86 about half the cost.
So why are you against me using atomic ops? I think you just
proved my point?
But as people have pointed out before,
having things like "attommic add N to X" and atomic_cmpxch()
is rather foolis because it would be better to implement what people
WANT, because what you end up doing is forcing everyone to bang
square pegs into round holes everywhere.
For example: what I want:
and INCREMENT
a DECREMENT
Why not have them available, optimised for each platform?
(many machines have these, and they can be synthesised on most
machines that don't, really cheaply) Unfortunatly GCC cannot
otimise an __asm add of 1 into an inc, or even an addi (add immediate).
I also want a mutex that just stores TRUE or FALSE into something
attomically. and returns TRUE (it succeded) or FALSE (it was not free)
but I'm forced to use CMPXCG(ptr, MTX_UNOWNED, curproc).
This is way overkill for what I want. I don't want the bloody curproc,
I want to exclusively lock something and I consider recursion a
fatal error.
As to what I do think we should do:
We should have primatives that are like:
struct exclusive_lock *xlock;
inline int xlock_get(xlock);
inline int xlock_drop(xlock);
struct six_lock *sxlock;
inline int six_reader(sxlock); (fails of there is a writer running or waiting)
inline int six_writer(sxlock); (fails if there are readers or writers)
struct recursive_spinlock *rslock;
inline int rslock_get(rslock);
inline int rslock_grop(rslock);
struct sleep_lock *slplock;
inline int slplock_get(slplock);
inline int slplock_drop(slplock);
etc.etc.
If you really want to you can implement them using common code,
(e.g a wrapper for what we have now)
but we wouldn't have the problem we saw a few weeks ago where
someone accidentally was sleeping on a lock that others were
spinning on.
We should also have MI operation macros that do what people want
to do rather than implement some virtual machine that other
machines may or may-not map to well.
I have patches to make SIX (reader/writer) locks as peers of
the mtx_xxxx code, and patches that just use them.
I would rather use the Peers than the client, but it seems to me that
if we are idealogically stuck on this horrible "one huge mutex that
does everything" then I need to add my stuff to that,
and I would need to get permission from whoever owns that.
before I do that. (I.e. add readers and writers counts).
It really makes mores sence to me if we had DIFFERENT locks, each
specialised for what it does, (maybe with the same debug extensions)
and different methods to access them. The if you need to change a
lock type, you change it in the containing struct definition and fix
all the places that gcc reports to you..
It also alows people to more easily micro optimise the methods. At
the moment you need to be confident enough that your optimisation is not
going to break some completely different kind of lock. it's all too
mixed up.. what happenned to "keep it simple"?
Personally I think we should fix this before we get so far into it
that it becomes impossible.
>
> So, if there are more than two atomic operations and they
> could have been protected by a single mutex, then the single mutex
> really is slightly better alternative. At three operations the
> mutex is a much better alternative.
>
> This is not an argument against, or for, your request.
>
> Chuck
>
> Julian Elischer wrote on: Fri, 15 Dec 2000 02:56:26 PST
> }CAn we have an atomic increment and decrement primative?
> }
> }presently we get:
> }
> }.L565:
> } movl $1,%eax
> }#APP
> } lock
> } addl %eax,4(%ebx)
> }
> }
> }the movl is totally useless and it would be
> }an absolutly trivial addition..
> }the question is;
> }is there a religious reason we don't already have it?
> }--
> } __--_|\ Julian Elischer
> } / \ julian@elischer.org
> } ( OZ ) World tour 2000
> }---> X_.---._/ presently in: Budapest
> } v
> }
> }
> }To Unsubscribe: send mail to majordomo@FreeBSD.org
> }with "unsubscribe freebsd-smp" in the body of the message
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A3A4630.1905D5D>