Concurrency, part one.

re: Concurrency, part one.

Jeff Parker — Mon, 14 Feb 2005 21:21:00 GMT

Ok, just so I am clear on the topic, this is a whole different type of threading? Yes still using theads but doing something different with them. Not like spawning a new thread to go do something while leaving your main UI thread free to show progress bars and update UI which is most commonly how I use threads? Or I might use threads in a thread pool to go get updates from multiple locations. That kind of thing is what I normally do.

re: Concurrency, part one.

Larry Osterman — Mon, 14 Feb 2005 21:26:00 GMT

It's not a different type of threading. What I'm trying to talk about is what happens once you decide that you want to have more than just you UI thread in your application and the gotchas that come from that decision.

The instant you have more than one thread in your application, there are a set of issues that occur that can bite you quite hard if you're not aware of them. Oftentimes you don't see them. But every once in a while they surface to cause massive problems.

re: Concurrency, part one.

Jeff Parker — Mon, 14 Feb 2005 21:55:00 GMT

Ahhh, ok the volatile stuff like some thread changing something another thread is not thinking is going to be changed by anything other than itself amonst a lot of other problem. The Things that make your app go BOOM or makes the operations guys want to hunt you down for hanging up their server in the middle of the night.

re: Concurrency, part one.

Brian — Mon, 14 Feb 2005 23:07:00 GMT

Maybe I can get a request in for you to touch on a (relevent) subject I've wondered about but never seen an answer to (I'm assuming of course that I know where this series of articles is headed):
Windows provides MsgWaitForMultipleObjects so that you can wait on e.g. a mutex and still process Windows Messages (which is critical for COM). Since a mutex is overkill for synchronizing access by threads within a process, I'd prefer to use a CRITICAL_SECTION. Here's the question: Do I have to worry about incoming messages while I'm blocked on EnterCriticalSection? If so, doesn't that severely limit the number of cases where I can use a CRITICAL_SECTION?
Also, if anyone is interested in Fibers, Raymond wrote an interesting series a few weeks ago. He also explained why you probably don't want to use them.

re: Concurrency, part one.

Paul D. Murphy — Tue, 15 Feb 2005 00:03:00 GMT

I love thread based concurrency. I do it all in .net cause it's a little easier with the abstractions. FWIW, if you are writing managed code this is really not that hard.

Let me put that into perspective. If you can understand the fundamentals of WaitHandles and Locks, it's really not that hard.

I try to explain to people that you have to think of a bunch of threads running as streams of water and dams. On a high level it's your job when programming concurrently to a: make sure the streams don't intersect and b: make sure the streams don't overflow. You can also think of it a routing traffic.

This is a good topic. I hope you won't mind me chiming in every so often. From reading your blog Larry it looks like you don't write alot of managed code and I can honestly say I don't write alot of unmanaged code. Can you spend at least one post of the differences between the two environments?

Thanks,
Paul

re: Concurrency, part one.

Larry Osterman — Tue, 15 Feb 2005 00:08:00 GMT

Paul,
You're right - I don't do a huge amount of coding in managed code, but I'll try to work something in. Most of the principles I'm describing still apply so..

re: Concurrency, part one.

Norman Diamond — Tue, 15 Feb 2005 02:08:00 GMT

> or as easy as you want to make it

Yes if you lock everything. Even consider two people using Notepad on the same file concurrently. You don't even need two CPU cores to do it, Terminal Services can deliver it to two users concurrently. Whoever saves it last wins.

Database systems (which also don't need two cores) have a certain amount of locking built in. If you want to be as simple as possible then you lock the entire database to prohibit all concurrent access. Complexity comes about by finding how to reduce the amount of locking.

re: Concurrency, part one.

Ryan Myers — Tue, 15 Feb 2005 02:53:00 GMT

One thing to keep in mind is that HT is only two cores in the loosest sense. With HT, you have two blocks of minimal processor state (i.e. registers, etc.) that share a set of ALUs, a single fetch/decode engine, and a single cache. The HT engine tries to divvy up the ALUs between the two HTs at each "step" in a way that presumably makes sense.

Unfortunately, this causes problems when you try to use conventional MP techniques on HT processors. The famous problem with this is spinlocking -- if you attempt to use a spinlock on an HT processor, the non-locked core will be starved for ALUs. You have to insert instructions to hint that the core is sleeping in order to pull it off, which XP does. There are also limitations on how one schedules ISR/DPC processing on an HT system.

In this sense, HT is more of a way to amortize the costs of pipeline stalls than true multiprocessing -- and that's why sometimes turning off HT gives you a total perf gain for tasks. Still, it's "close enough" for many purposes, if anticipated, and we should make use of what we've got.

re: Concurrency, part one.

Andrew Shuttlewood — Tue, 15 Feb 2005 11:05:00 GMT

Have you thought of looking at the prospect of non shared-state concurrency? Ie, using messages to communicate between threads with immutable state. (Thread A creates an object and writes it to a message queue, Thread B reads it, creates a new object rather than mutating the first object and writes that to another message queue), etc.

re: Concurrency, part one.

Frederik Slijkerman — Tue, 15 Feb 2005 11:39:00 GMT

> > or as easy as you want to make it
> Yes if you lock everything.

It is amazing how easy it is to introduce deadlocks if you lock everything. I have been bitten by this more than a couple of times.

re: Concurrency, part one.

Andreas Häber — Tue, 15 Feb 2005 14:50:00 GMT

A good serie of articles about HT, TLP(Thread Level Parallellism) and/or multi-core CPUs are [1], [2] and [3] from Ace's Hardware. Note that this is from a hardware architecture point of view, and not much about software.

Looking forward to read this serie, Larry :)

[1] http://www.aceshardware.com/read.jsp?id=65000292
[2] http://www.aceshardware.com/read.jsp?id=60000312
[3] http://www.aceshardware.com/read.jsp?id=65000333

Great concurrency series

Ben Reichelt's Blog — Tue, 15 Feb 2005 19:02:00 GMT

re: Concurrency, part one.

Mike Dimmick — Tue, 15 Feb 2005 16:24:00 GMT

Brian: a CRITICAL_SECTION is a combination of a small number of variables accessed using interlocked operations to see whether it can be acquired immediately/with a given amount of spinning, and a kernel object to wait on with WaitForSingleObject if the variables indicate that it cannot.

As such, if it doesn't enter the critical section immediately, yes, you will be blocked and unable to handle window messages. You should try to keep the amount of time spent in the critical section to a minimum - perhaps perform all computations before entering the critical section and updating the protected variables, or enter the critical section, copy the values to local variables, then leave.

Obviously if you need to read the protected values, process them, then write back you'll need to hold the section for longer periods, unless you're willing to abandon the results if you discover the source values have changed. It would be better to perform this processing on another thread so that the UI thread remains responsive - post a message back to the UI thread to indicate completion.

re: Concurrency, part one.

Skywing — Tue, 15 Feb 2005 17:09:00 GMT

EnterCriticalSection will not dispatch messages while blocking.

re: Concurrency, part one.

Larry Osterman — Tue, 15 Feb 2005 19:00:00 GMT

Mike, you're ahead of me :) THat's article 3 :)

Concurrency, Part 2 - Avoiding the problem

Larry Osterman's WebLog — Tue, 15 Feb 2005 23:48:00 GMT

Concurrency, Part 2 - Avoiding the problem

Larry Osterman's WebLog — Wed, 16 Feb 2005 00:50:00 GMT

re: Concurrency, part one.

Rick Brewster — Wed, 16 Feb 2005 20:50:00 GMT

Hey Larry, I've written some topics on this in my blog as well. Check them out ... start with the Dec. 30 2004 entry and go onward.

Concurrency, Part 8 - COncurrency for scalability

Larry Osterman's WebLog — Tue, 01 Mar 2005 00:25:00 GMT

Concurrency, Part 8 - Concurrency for scalability

Larry Osterman's WebLog — Tue, 01 Mar 2005 00:31:00 GMT

re: Concurrency, part 7 - Why would you ever want to use concurrency in your application?

Larry Osterman's WebLog — Tue, 01 Mar 2005 02:08:00 GMT

Larry Osterman s WebLog Concurrency part one | Menopause Relief

Larry Osterman s WebLog Concurrency part one | Menopause Relief — Wed, 10 Jun 2009 04:18:04 GMT

PingBack from http://menopausereliefsite.info/story.php?id=1234