Agreed (in fact, the architecture manual indicates that the lock is implied
in xchg)
/simgr
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, October 15, 2002 11:15 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
Yes, that’s how I read the manual too. One instruction that doesn’t need the
LOCK prefix to be atomic is XCHG, but that’s not very useful in this context
!
Alberto.
-----Original Message-----
From: Graham, Simon [mailto:xxxxx@stratus.com]
Sent: Tuesday, October 15, 2002 11:01 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
The architecture manual indicates that reads/writes to byte, word aligned
shorts and dword aligned ulongs are atomic (Volume 3, section 7.1.1).
However, this doesn’t provide atomic read-modify-write which you need in
order to do the MP safe increment/decrement (and section 7.1.2.2 indicates
that the LOCK prefix can be used to get atomic inc/dec).
/simgr
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, October 15, 2002 10:29 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
Dan, where’s that documented ? I had this same idea in the back of my mind,
but I went through the P4 documentation and I can’t find it.
Alberto.
-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Tuesday, October 15, 2002 5:26 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
operation on byte syze are atomic
----- Original Message -----
From: Bi mailto:xxxxx Chen
To: NT Developers Interest List mailto:xxxxx
Sent: Monday, October 14, 2002 9:45 PM
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
I am not sure why byte counter has any thing to do with an atomic operation.
If one wants to do an atomic operation, lock prefix must be used on Intel
IA32.
Bi
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Monday, October 14, 2002 11:24 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
He said byte counters, no need to lock.
Alberto.
-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Monday, October 14, 2002 2:22 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
On SMP
_asm lock inc counter
_asm lock dec counter
Bi
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com
mailto:xxxxx]
Sent: Monday, October 14, 2002 7:27 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
The concurrent access should be handled by the MESI protocol at the system
bus level without any problem. My gut feeling - but I’m a really low level
programmer, so, people may disagree - is that if you’re talking Pentium
only, the best way to do it is just to include that one “inc counter” or
“dec counter” instruction in your programs, using a one-line inline assembly
instruction:
_asm { inc counter }
_asm { dec counter }
Alberto.
-----Original Message-----
From: xxxxx@attbi.com [mailto:xxxxx@attbi.com mailto:xxxxx]
Sent: Sunday, October 13, 2002 11:15 PM
To: NT Developers Interest List
Subject: [ntdev] Spinlock vs. InterlockedAdd
I track a byte count that is incremented at DISPATCH level and decremented
at PASSIVE level on a multiprocessor machine. It is critical that the
count be accurate. I currently have the counter protected by a spin lock,
but I now wonder if InterlockedAdd() will produce the same result with
less overhead.
For a counter such as this, is InterlockedAdd() a better choice? Why?
If I understand correctly, in a multiprocessor system, spin lock overhead
is directly related to spin lock contention.
It is my understanding that the InterlockedAdd() function utilizes an
atomic read/modify/write cycle. But, I’m wondering if another CPU in a
multiprocessor system could be accessing the same memory location
simultaneously. Do SMP machines allow simultaneous memory access?
Thank you for your thoughts on this.
Brad
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
—
You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>