Spinlock vs. InterlockedAdd

NTDEV
1

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

2

>> InterlockedAdd

Way less overhead than using a spinlock.

> I’m wondering if another CPU in a
> multiprocessor system could be accessing the same memory location
> simultaneously.

It wont happen while using Interlocked functions family.

> Do SMP machines allow simultaneous memory access?

Yes, they do. But your safe with Interlocked functions, because they
guarantee by design that the memory bus is locked and the operation is
atomic. On X86 architecture, this is accomplised by using a lock prefix.
This guarantees that only one CPU will access that memory location at a
given time.

----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Monday, October 14, 2002 6:14 AM
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@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

3

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 }

or something like that. Saves the need for spinning and takes advantage of
the machine’s instruction set. Of course you can’t do that in a RISC
machine, but you can easily ifdef it.

Alberto.

-----Original Message-----
From: xxxxx@attbi.com [mailto:xxxxx@attbi.com]
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.

4

_asm { inc counter }
_asm { dec counter }

Those are atomic only for counters which are of byte size. dword and word
increment are not atomic on intel architecture, unless a lock prefix is
used.

----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Monday, October 14, 2002 5:26 PM
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 }
>
> or something like that. Saves the need for spinning and takes advantage of
> the machine’s instruction set. Of course you can’t do that in a RISC
> machine, but you can easily ifdef it.
>
> Alberto.
>
>
>
>
> -----Original Message-----
> From: xxxxx@attbi.com [mailto:xxxxx@attbi.com]
> 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@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

5

InterlockedXXX is better for your purpose. It does not raise System IRQL.

In fact, Spinlock loops InterlockedCompareExchange on some variable.
SpinLock is a lock. It means once you aquire it, no one else will get until
you release it. This means thread could be spinning on this lock, waste CPU
cycles.

Bi

-----Original Message-----
From: xxxxx@attbi.com [mailto:xxxxx@attbi.com]
Sent: Sunday, October 13, 2002 8: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@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

6

On SMP

_asm lock inc counter
_asm lock dec counter

Bi

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
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]
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%%

7

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%%

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>

8

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.</mailto:xxxxx></mailto:xxxxx>

9

And what is really that wrong with
InterlockedIncrement/InterlockedDecrement functions - which are actually
compiler intriniscs now -
that you’d want to use these inline x86 assembly versions which will
break your driver on other platforms?

-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Monday, October 14, 2002 11:22 AM
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]
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]
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@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

10

Maybe I’d rather be tied to the hardware than be tied to a compiler ? And if
I talk to the iron I can see what I’m doing, if I use some call I have to
trust someone else and I don’t necessarily see what I’m doing unless I dig.
I personally like to keep my interactions with the OS to a bare minimum.
Specially if I don’t need to bother about other platforms, or if I don’t
mind specialcasing at compile time.

Alberto.

-----Original Message-----
From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, October 14, 2002 3:00 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd

And what is really that wrong with
InterlockedIncrement/InterlockedDecrement functions - which are actually
compiler intriniscs now -
that you’d want to use these inline x86 assembly versions which will
break your driver on other platforms?

-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Monday, October 14, 2002 11:22 AM
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]
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]
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@windows.microsoft.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%%

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.

11

We should use InterlockedXXX. I just want to point out Alberto missed the
lock prefix.

Anyone still using Win2k on Alpha?

Bi

-----Original Message-----
From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, October 14, 2002 12:00 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd

And what is really that wrong with
InterlockedIncrement/InterlockedDecrement functions - which are actually
compiler intriniscs now -
that you’d want to use these inline x86 assembly versions which will
break your driver on other platforms?

-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Monday, October 14, 2002 11:22 AM
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]
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]
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@windows.microsoft.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%%

12

Bi is right, I was sloppy and relied on an old memory. On P4, the effect of
the LOCK prefix is to activate the cache protocol, and unlike the Pentium,
the LOCK pin in the system bus will not be pulled active if the data is
already cached: that increases the performance. And of course it doesn’t
depend on the width of the data item.

Alberto.

-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Monday, October 14, 2002 3:14 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd

We should use InterlockedXXX. I just want to point out Alberto missed the
lock prefix.

Anyone still using Win2k on Alpha?

Bi

-----Original Message-----
From: Ravisankar Pudipeddi [ mailto:xxxxx@windows.microsoft.com
mailto:xxxxx ]
Sent: Monday, October 14, 2002 12:00 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd

And what is really that wrong with
InterlockedIncrement/InterlockedDecrement functions - which are actually
compiler intriniscs now -
that you’d want to use these inline x86 assembly versions which will
break your driver on other platforms?

-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com mailto:xxxxx]
Sent: Monday, October 14, 2002 11:22 AM
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@windows.microsoft.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%%

—
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.</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

13

Yup, I wrote “byte count”. But what I meant was a count of bytes. I was
not trying to convey the bit width of the counter itself. Sorry for the
confusion.

Thank you all for the excellent input. I prefer the platform independent
DDK interfaces over coding assembly in the drivers that I write, so I’ve
gone with InterlockedExchangeAdd().

Thank you again.

Brad

Alberto wrote:
------_=_NextPart_001_01C273AE.E30F9C30
Content-Type: text/plain;
charset=“iso-8859-1”

He said byte counters, no need to lock.

Alberto.

-----Original Message-----

14

Alberto,

Did you write the compiler? The Linker? The assembler? Really, dude, you
trust a LOT of third party software, but you won’t trust an intrinsic
interlocked function that is provided by the DDK? Go look at it in a
debugger and then say you can’t trust it. It’s brain dead simple code.

Gary G. Little
Have Computer, Will Travel …
909-698-3191
909-551-2105

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> Maybe I’d rather be tied to the hardware than be tied to a compiler ? And
if
> I talk to the iron I can see what I’m doing, if I use some call I have to
> trust someone else and I don’t necessarily see what I’m doing unless I
dig.
> I personally like to keep my interactions with the OS to a bare minimum.
> Specially if I don’t need to bother about other platforms, or if I don’t
> mind specialcasing at compile time.
>
> Alberto.
>
>
>
> -----Original Message-----
> From: Ravisankar Pudipeddi [mailto:xxxxx@windows.microsoft.com]
> Sent: Monday, October 14, 2002 3:00 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Spinlock vs. InterlockedAdd
>
>
> And what is really that wrong with
> InterlockedIncrement/InterlockedDecrement functions - which are actually
> compiler intriniscs now -
> that you’d want to use these inline x86 assembly versions which will
> break your driver on other platforms?
>
> -----Original Message-----
> From: Bi Chen [mailto:xxxxx@AppStream.com]
> Sent: Monday, October 14, 2002 11:22 AM
> 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]
> 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]
> 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@windows.microsoft.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%%
>
>
>
> 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.
>
>
>
>

15

RE: [ntdev] RE: Spinlock vs. InterlockedAddoperation on byte syze are atomic
----- Original Message -----
From: Bi Chen
To: NT Developers Interest List
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]
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]
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%%

16

-----Original Message-----
From: “Dan Partelly”
To: “NT Developers Interest List”
Date: Tue, 15 Oct 2002 12:26:04 +0300
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd

> RE: [ntdev] RE: Spinlock vs. InterlockedAdd
>
> operation on byte syze are
> atomic
> ----- Original Message -----

In fact there is no intrinsic InterlockedIncrement/Decrement operator
defined for anything other than 32bit targets. However the original
poster misstated his objectives and thereby allowed alberto yet another
opportunity to present his case for never doing anything using OS
defined interfaces :slight_smile: The poster was tracking bytes (a byte counter)
not using an 8-bit location as a counter.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

17

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 Chen mailto:xxxxx
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%%

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>

18

Methinks the OS defines far too many interfaces.

Alberto.

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Tuesday, October 15, 2002 8:26 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd

-----Original Message-----
From: “Dan Partelly”
To: “NT Developers Interest List”
Date: Tue, 15 Oct 2002 12:26:04 +0300
Subject: [ntdev] RE: Spinlock vs. InterlockedAdd

> RE: [ntdev] RE: Spinlock vs. InterlockedAdd
>
> operation on byte syze are
> atomic
> ----- Original Message -----

In fact there is no intrinsic InterlockedIncrement/Decrement operator
defined for anything other than 32bit targets. However the original
poster misstated his objectives and thereby allowed alberto yet another
opportunity to present his case for never doing anything using OS
defined interfaces :slight_smile: The poster was tracking bytes (a byte counter)
not using an 8-bit location as a counter.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

—
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.

19

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 Chen mailto:xxxxx
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.</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

20

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%%

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>