Share a Draft: Multi-Threaded Programming 3: Locking, Lock-Free, Wait-Free

[Joseph Simons]

This took a little longer than I normally would like, since I thought I was going to actually get into implementing some actual code. Though the length of the post was getting a bit too long with it, so I decided to expand upon the terms and problems that you can encounter instead and will cover actual locking and lock-free code examples in future posts.

I don't have any images created yet, but you can easily see my notes about where I am planning them and what they will cover. So please review just the posted content and make sure that everything seems well written and explained and that I didn't make any obvious errors (plus any other suggestions you might have):

http://www.altdevblogaday.com/?p=30990&shareadraft=baba30990_53405782e7978

This draft should be available for a week for review purposes. Thanks!
-Joseph-

[Thomas Young]

Hi Joseph,

Looks good to me.
(I think it's a good idea to break it down into bite sized instalments like this.)

Thomas

[Rick Lamb]

Have you considered adding some discussion about algorithms reducing the need for synchronization and locking.
In particular the pattern of using thread local variables to buffer resources/actions to avoid locking on every function call.

Rick

--
You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joseph Simons]

I haven't had much experience with those types of algorithms myself. I have read about a few types of locks that make use of them, but not much more than that.

Typically, I have only really used thread-local variables when I am converting single-threaded code that has heavy use of global variables (and refactoring the code to eliminate those is prohibitive). Usually just local variables on the stack are sufficient, I find.

-Joseph-

[Oliver Franzke]

Hi Joseph. Great work with the article!

[Paul Evans]

Hi Joseph, this was a decent stab at the subject.

I have two observations. One grammatical and the other just my thought on the matter.

Therefore, it is actually good practice to start with using simple locks to protect shared data.,

1) You've got double punctuation, guess you meant to just have the full-stop.

2) I disagree with the guidance because it encourages locks around "shared data" that may algorithmically never truly be in contention.  Anecdotally a couple of years ago I had the misfortune of campaigning to be allowed to then eventually taking out locks where the previous coder had peppered them everywhere in a few core libraries - even in property getters and setters on individual members of plain old data objects.  Once those locks are in there for long enough and a programmer leaves a project... other coders get scared about removing them because "there must have been a reason... ?"  It really was crippling performance in those libraries for no reason and served as a bad example.

I am sure the charts etc you add will help illustrate and define what data actually needs protecting.

--

[Alex 'darbotron' Darby]

Hi Joseph

Good stuff :)

1) As with feedback I gave to one of your previous posts, I think there are a few places where paragraphs could be broken up more so that the individual points they make are clearer.

2) I look forward to seeing it with the diagrams :)

3) To Rick and Paul's points - there are a few general points to be made about philosophy of programming in with multi-threading IMO.

With all the super-parallel stuff that is going off right now, and only going to get worse in the future, these sort of philosophical angles need discussing at some point I think ;)

If you've not seen it this is an epic talk (from 2009!!) that discusses this issue philosophically: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey. 

The stuff in the video isn't a solution I'd necessarily want to implement but very interesting nevertheless...

At the very least it might be really useful to discuss the key questions: "Does this data need synchronising?" -> "how can I synchronise it? (this is what you're currently discussing in yr blogs)" -> "how _should_ I synchronise it? (what I assume you're moving on to as the series progresses)" -> "what is different about code that expects to be primarily parallel vs. stuff that expects to be primarily serial?" 

TBH I wouldn't consider myself an expert on this stuff, I've written quite a lot of threaded code (e.g. network transport, threaded rendering etc.) but not heavily parallel code like SPUs/PS4/xbone...

Alex

[Joseph Simons]

Paul, thanks for the suggestions. I understand what you mean by how my advice could be seen as suggesting to just throw locks around everything, and I guess on some level that might be what I mean. However, I do caution against it by suggesting to keep an eye on performance and investigate other solutions if they become a bottleneck. Though I might add some qualifications to some of the statements to hopefully make the advice a little better. It is difficult to give general guidelines sometimes because things with multithreading get pretty specific very quickly. That is why I am going to be moving on to code next where I hope to show some of those specifics (though it will just be simple teaching code, not stuff directly pulled from shipped games due to all the legal reasons involved).

Alex, thanks for the link. Hopefully I can get around to watching that at some point soon. The philosophical angle is an interesting way to think about things. Might be good for when the series is winding down as a way to look at things in a larger context. Right now I think I have done enough writing and think it is time to get to the code (sort of wish I got to it sooner, but I felt giving a good foundation was important too). I will eventually be getting into examples that are linear and convert them to parallel code, which I think would be a good place to work in the answers to "Does this data need synchronizing?" (and reiterate on the "How" and "How should" parts perhaps). Definitely food for thought.

I think I am going to keep the paragraphs about the length that they are. I just am not much of a fan of really short paragraphs. Maybe it is just a holdover from the various writing courses from school, or just a personal taste. But I appreciate the suggestion, since it does give me a different view of how things are.

Thanks everyone for all the feedback so far!

-Joseph-

--