Concurrency, Part 9 - APIs that enable scalable programming

re: Concurrency, Part 9 - APIs that enable scalable programming

Norman Diamond — Thu, 03 Mar 2005 01:06:00 GMT

> InitializeCriticalSectionAndSpinCount API

For multiprocessor systems the advantage is obvious, as long as the thread trying to enter the critical section is on a different processor from the thread that already owns the critical section. The current owner might really leave quickly.

But for uniprocessor systems it still looks like a disadvantage. The caller still has to go to sleep and the kernel still has to switch the context back to the current owner at some time in order for the current owner to ever have a chance of exiting the critical section. So why waste CPU time spinning instead of letting some other executable thread do something? Sure you've reduced lock convoys but you've done it by turning the same CPU cycles into pure waste.

You say that this API was implemented in Windows 98. There were no multiprocessor Windows 98 implementations, right? How could this ever be anything other than a loss on Windows 98?

If you want the caller of EnterCriticalSection to get the rest of the quantum that it was going to have, then the theoretical answer is to give that thread a minor priority boost and the rest of the quantum that it was using. But from everything I've read about Windows, priorities still aren't fine-grained enough to do this without impinging on the genuinely higher priorities of higher priority tasks. Anyway, the theoretical answer isn't to spin when you've only got one CPU.

> Sorry, I just noticed that this didn't get
> posted yesterday - I don't know what
> happened, but...

The race between the process that submits threads for posting and the thread that actually posts them went the other way ^_^

re: Concurrency, Part 9 - APIs that enable scalable programming

Larry Osterman — Thu, 03 Mar 2005 01:48:00 GMT

Good points Norman.

I suspect that on Win98, the "and spin count" part of the API was a NOP (but I don't know, having never written code for Win98). My suspicion is that they just added a wrapper for the API.

For UP machines ICSASC is almost always a loss (I can't think of a situation where it's a win). But the vast majority of machines are MP machines these days, so it's more important. Also, the big reason you use this API is if you're trying to remove lock convoys in your application. If you're seeing lock convoys in your application then it's likely to be a server type application. And...

re: Concurrency, Part 9 - APIs that enable scalable programming

Norman Diamond — Thu, 03 Mar 2005 05:43:00 GMT

> But the vast majority of machines are MP
> machines these days

Now the principal asks why you misspelled "servers" ^_^

re: Concurrency, Part 9 - APIs that enable scalable programming

Dave Sellars — Thu, 03 Mar 2005 09:12:00 GMT

MSDN says that InterlockedIncrement() returns the RESULTING value, not what you said (the previous value). This is an important difference. BTW, excellent column, Larry, I just discovered it and am enjoying it immensely.

re: Concurrency, Part 9 - APIs that enable scalable programming

Giampiero De Ciantis — Thu, 03 Mar 2005 16:11:00 GMT

This is more of a .NET question, but what is the difference between concurrency with threads and asynchronous events? Is it the same under the hood or does the CLR do something funky?

Would the basics that you mention work for message passing languages like Erlang?

How does Micro C++ fit change the equation?

I now you already mentioned that you aren't the expert in concurrency. Just fielding the questions to see if you may now any of the answers.

re: Concurrency, Part 9 - APIs that enable scalable programming

Matt Stupple — Thu, 03 Mar 2005 18:16:00 GMT

What about the memory barriers imposed by use of the InterlockedFoo() operations? My (very superficial) understanding is that they shouldn't be viewed as a panacea for 'lock free' programming because of the potential costs of the memory barriers...?

re: Concurrency, Part 9 - APIs that enable scalable programming

Larry Osterman — Thu, 03 Mar 2005 18:21:00 GMT

Matt, you're right, there are memory barriers, and they do have a cost associated with them. But their cost is effectively 0 when compared to the cost of a context switch.

Giampiero, I don't think I can answer that, I don't know how the CLR handles asynchronous events.