There were a surprising number of talks on C, though mostly just to confirm that C is a dying language, a "zombie language" as Uncle Bob put it, even if there is still a niche or two where it is the best fit.

There was also a fair number of sessions on testing, especially TDD (even TDD in C), and a few sessions on other agile practices.

However, the big topic of the conference was C++11. Nicolai Josuttis ran a full day pre-conference tutorial on the C++11 library, and then there were sessions on the best and worst features of the C++11 library, C++11 for everybody, C++11 for the rest of us, C++11 allocators, writing generic code with C++11, the C++11 concurrency facilities, an interactive C++11 programming session, and even a C++11 pub quiz (with free beer!)

The other big topic was concurrency and parallelism, with 6 presentations, including two by me. Actors and Dataflow seemed to be a common theme — it looks like these ideas are finally filtering into the mainstream now that everyone and his dog has a multicore computer in their pocket. Not only did Russel, Jason and I reference them in our presentations, but several of the developers I spoke to had implemented their own actor or dataflow libraries, or were interested in using one.

My presentations

My own presentations went well. My first one (on Dataflow, Actors and High Level Structures in Concurrent Applications, on Thursday afternoon) was packed out. There were quite a few interesting questions from the audience, and someone told me it was the best presentation at the conference, which was really nice to hear. Several people asked about slides and the code samples, and I promised to make them available. The slides are here and the code samples here

My second presentation was the C++11 concurrency tutorial on Saturday morning. I was presenting in the first slot after the keynotes, and the speakers dinner was the night before, so a lot of people had been looking rather the worse for wear in the beginning. However, the room was almost full again, and the audience seemed to be awake — yet again there were many interesting questions that showed people were paying attention. The slides for are here and the code samples here

My book

My book was only published a couple of months before the conference, so it was exciting to see so many people clutching copies. Apparently the Blackwell's stall sold out, which was nice for me, but unfortunate for those that didn't manage to get a copy. If you wanted a copy then you can buy it direct from Manning, or from amazon.com, or amazon.co.uk.

Posted by Anthony Williams
[/ news /] permanent link
Tags: accu, conference, concurrency, c++

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

This year I'm presenting two sessions. The first is tomorrow, at 4pm: Dataflow, actors, and high level structures in concurrent applications. In this session, I'll be talking about high level approaches for writing concurrent architectures including actors and dataflow architectures, and giving example code in multiple languages, including C++ and Groovy.

My second session is on Saturday at 11am, C++11 concurrency tutorial. This session will cover how to use the new C++11 thread library, as well as various guidelines for avoiding race conditions and deadlocks.

Hope to see you there!

Posted by Anthony Williams
[/ news /] permanent link
Tags: conferences

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

My book C++ Concurrency in Action was finally published on 29th February 2012, after 4 years of work. It's hard to believe that I can actually hold a copy in my hand; it's just been files on my computer for so long.

My book is a tutorial and reference to the thread library from the new C++11 standard. It also provides various guidelines for writing and testing multithreaded code, as well as sample implementations of thread-safe data structures and parallel algorithms

If you haven't already got a copy, you can order one direct from Manning, or from amazon.com, or amazon.co.uk. Alternatively, copies should be available at the ACCU 2012 conference in Oxford this week.

Discount on Just::Thread

If you have purchased the book then send a copy of your receipt or other proof of purchase to info@justsoftwaresolutions.co.uk for a 50% discount on a single user license of Just::Thread, our implementation of the C++11 thread library described in the book for Microsoft Visual Studio on Windows, and g++ on Windows, Linux and MacOSX.

Posted by Anthony Williams
[/ threading /] permanent link
Tags: c++, concurrency, book, multithreading

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

2011 was another good year for me. Sales of Just::Thread, my implementation of the C++11 thread library continue to grow, and my book is finally in typesetting, and nearly ready for printing. We had hoped to get it done by the end of 2011, but last-minute corrections scuppered that. It should now be done relatively quickly.

It's also been a big year for the C++ community: C++11 is now an official ISO standard. This is the culmination of many years of hard work from a huge number of people, so it's good to see it finally done.

Popular articles

As is my custom, here's a list of the 10 most popular articles and blog entries from the Just Software Solutions website in 2011.

1. Implementing a Thread-Safe Queue using Condition Variables
   A description of the issues around writing a thread-safe queue, with code.
2. Implementing drop-down menus in pure CSS (no JavaScript)
   How to implement drop-down menus in CSS in a cross-browser fashion (with a teensy bit of JavaScript for IE).
3. Importing an Existing Windows XP Installation into VirtualBox
   This article describes how I recovered the hard disk of a dead laptop to run as a VM under VirtualBox.
4. Multithreading in C++0x part 1: Starting Threads
   This is the first part of my series on the new C++11 thread library. Links to the remaining parts are at the end of the article.
5. Thread-Safe Copy and Move Constructors
   This is a guest post by Michael Spertus on writing copy and move constructors for objects with internal locks.
6. Multithreading in C++0x part 2: Starting Threads with Function Objects and Arguments
   This is the second part of my series on the new C++11 thread library, which covers using callable objects when starting threads, and passing arguments to the thread function.
7. Introduction to C++ Templates
   My basic introduction to C++ templates.
8. Multithreading in C++0x part 8: Futures, Promises and Asynchronous Function Calls
   This is the eighth part of my series on the new C++11 thread library, which covers the "futures" mechanism for passing data between threads.
9. Thread Interruption in the Boost Thread Library
   A description of the thread interruption feature of the Boost Thread library.
10. Deadlock Detection with just::thread
    This article describes how to use the special deadlock-detection mode of our just::thread C++11 thread library to locate the cause of deadlocks.

What's coming in 2012?

Will 2012 be even better than 2011? I hope so. As I already mentioned, my book will finally be printed, which will be a big relief for me.

What are you looking forward to in 2011?

Posted by Anthony Williams
[/ news /] permanent link
Tags: popular, articles

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

I studied Physics at college, and there was very little programming taught as part of the course. That didn't bother me though; I'd taught myself to program up until then, and I wasn't going to stop now. The big benefit I got from computing at college was access to the internet, and access to C and C++ compilers. I could program in BASIC, Pascal and a couple of forms of assembly language, and I'd eagerly read Stan Lippman's C++ Primer and written out (on paper!) some C++ code, but I hadn't yet had a C++ compiler to try out my programs on.

I wrote several C++ programs before I even considered writing a plain C program, but I probably typed in and compiled the classic printf("hello world\n"); C program to check everything was working before I compiled any C++.

Usenet

My strongest memories about learning C are about learning from usenet. Though I had access to C compilers at college, access to experts was not so readily available unless you were studying computing. With access to the internet, I didn't need local experts though — usenet provided access to experts from across the world. I read comp.lang.c and comp.lang.c++ avidly, and taught myself both languages together. The usenet community was invaluable to me. The wealth of knowledge that people had, and their willingness to share with newbies was something I really appreciated.

I remember struggling over file handling, and getting the arguments to scanf right; I remember puzzling over the poor performance of a program and having someone kindly point out that my code was doing malloc and free calls in a tight loop. Though I tend to answer more questions than I ask these days, I still hang out on newgroups such as comp.lang.c++ today. It seems that for many people StackOverflow has replaced usenet as the place to go for help, but the old-style newsgroups are still valuable.

Ubiquity

Back then, C++ compilers were in their infancy. Templates didn't work on every compiler, there was no STL, and many platforms didn't have a working C++ compiler at all. I consequently wrote a lot of C — every platform had a C compiler, and my C code would work on the college PCs, my PC (when I saved up enough to buy one), the University's Unix machine, and the Physics department workstations. The same could not be said for C++.

The ubiquity of C is something I still appreciate today, and this is only possible because Dennis Ritchie designed his language to be portable to multiple platforms. Though "implementation defined" behaviour can be frustrating when the implementation defines it a different way to how you would like, it is this that enables the portability. You want to write code for a DSP that only handles 32-bit data? Fine: make char, short, int and long all 32-bits. What if your machine has 9-bit bytes? No problem: just make char 9 bits, and everything else a convenient multiple of that.

C is the basic lingua-franca of the computing world. It is a "portable assembly language". These days I use C++ where I can because it allows a higher level of abstraction, and easier expression of intent without compromising on the performance you'd get with plain C, but it's not as portable, and wouldn't be possible without C.

The computing world owes a lot to Dennis Ritchie.

Posted by Anthony Williams
[/ general /] permanent link
Tags: C, nostalgia

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

The travesty of ICT

Our children do not get taught anything at school about how computers work, or how to program them, and are unlikely to. Andrew says he found that "the study of computer science for British children ends at about age 11." This doesn't tally with my experience of primary schools — they are never taught any computer science. Local secondary schools are proud of their ICT suites, with office programs and image editing programs galore, but not a single class on the basics of computers and programming.

Part of the problem is the complexity of modern computers. Whereas the computers we grew up with (the Dragon 32, BBC Micro, ZX Spectrum, Commodore 64, etc.) were simple beasts, and booted into a programming environment (BASIC), modern computers are complex beasts with a swish graphical OS with no native programming environment. Yes, you can use Javascript in a browser, or the macro language in office programs, but it's not the same. PCs do not invite programming the same way that the older computers did, and you have to go out of your way to provide a basic programming environment.

Schools could overcome this hurdle, and provide programming environments, but they don't. Instead they teach everyone how to use the latest versions of office programs, despite the fact that next year's release will have a different UI, and different capabilities. Yes, children need to be computer-savvy, due to the prevalence of computers in everyday life, but they don't need to be experts in using word processors. Rather, they should be taught how to learn to use the programs, the things that are common about them (e.g. menus), how to get help (the help menu, Google), and so forth, and then taught about how computers work. Yes, use a word processor for writing the occasional thing in English, or use a spreadsheet for doing some data analysis in Geography, but the "computing" lessons should be about programming and how computers work at the basic level, rather than how to use popular software.

I think this lack of teaching about the basics of computing has a wider effect, as well as the lack of new programmers. The computer is something that people don't understand, but which they rely on. This can give people a sense of powerlessness, especially when it does something unexpected. I've had to help people who've been all in a panic because they "lost their work". It didn't appear in the list that was presented in the "open file" dialog, so it was "lost". Somehow they had saved it in a different directory, and their lack of understanding about the file system meant they didn't know how to find it, and panicked — the computer that they relied on had "lost" their important work. Teaching about the basics of modern operating systems (rather than the specifics of the software package being used) would have alleviated this fear.

Addressing the Problem

So, what is to be done? Firstly, as programming parents we can teach our children about computers and programming, which is something that my wife and I have started doing. But beyond that, we need to make the schools, colleges and government aware of the issues.

Andrew points to the Computing at School working group and the Behind the Screen project, both of which seem promising. However, without support these projects will fizzle, and our children will continue to be taught how to use office software rather than computing principles.

Posted by Anthony Williams
[/ general /] permanent link
Tags: computing, education, schools

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

This release adds official support for gcc v4.4 on Centos 6, so Just::Thread is now supported on Centos, Fedora, Ubuntu and Debian Linux distributions, as well as Microsoft Windows and Apple MacOSX.

The main change with this release is an enhancement to the std::async implementation. With this enhanced scheduler, the default launch policy (std::launch::async | std::launch::deferred) will defer forcing a decision until either enough resources become available to schedule the task as std::launch::async, or the task is forced to be scheduled as std::launch:deferred by a call to a waiting function (get(), wait(), wait_for() or wait_until()). This will allow more tasks to be scheduled as std::launch::async overall, and allow your application to make better use of the available hardware concurrency.

The implementation of recursive mutexes has been overhauled, leading to much faster lock and unlock times than in previous releases.

This release also provides debugger visualizers for Microsoft Visual Studio, to better show the state of Just::Thread objects such as futures. This will provide greater insight into the state of your program, and allow easier debugging.

Purchase your copy and get started with the C++0x thread library now.

As usual, existing customers are entitled to a free upgrade to V1.7.0 from all earlier versions.

Posted by Anthony Williams
[/ news /] permanent link
Tags: multithreading, concurrency, C++0x

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

This guest column discusses writing thread-safe constructors. As we will see, this is more difficult than it seems. Fortunately, we will also see that C++11 offers a very pretty solution to this problem that nicely illustrates the synergy of the new features introduced in C++11.

The problem

If you have a class that supports locking of objects to serialize access to a given object, you probably want the class' copy constructor and move constructor (if it has one) to lock the source object to get a consistent snapshot of the source object so the destination object isn't messed up if the source changes in the middle of the copy or move.

This isn't nearly as easy as it sounds. In the following class, a mutex is used to try to enforce the invariant that i_squared should always be the square of i.

class A {
public:  A(_i = 0) { set(_i); }
  set(int _i) {
    std::lock_guard<std::mutex> lock(mtx);
    i = _i;
    i_squared = i*i;
  }
  ...
private:
  std::mutex mtx;
  int i;
  int i_squared;
};

Unfortunately, the default copy constructor doesn't acquire the mutex, so in code like the following, f can copy a "half set" version of a if another thread modifies a at the same time.

void f(A &a) 
{
  A a2 = a;
  ...
}

First attempt

A naive attempt is to acquire the lock in the constructor body just like in a thread-safe method.

class A {
public:
  A(const A &a) : i(a.i), i_squared(a.i_squared) {
    std::lock_guard<std::mutex> lock(a.mtx); // Too late!
  }
  ...
};

Unfortunately, this fares no better as i and i_squared are copied before we acquire the lock.

Second attempt

One approach would be to simply not lock in the copy constructor at all and just manually lock objects you want to copy:

void f(A &a)
{
  std::lock_guard<std::mutex>
  lock(a.mtx);
  A a2 = a;
  ...
}

This approach deserves careful consideration. For classes which are not usually shared between threads or which need locking granularity at a different level than their internal operations, managing locks within the class can be an antipattern. This concern was a primary reason why C++11 does not have an equivalent to the SynchronizedCollection wrapper found in Java and C#. For example, synchronized collections make it easy to inadvertently loop through a collection believing your code is thread-safe even though the collection could change between individual operations on the collection during the loop. Of course, if we decide not to have A's copy constructor lock, then A::set() should not lock either.

Still, it remains a very common and useful pattern for classes designed for shared use to have all their internal operations acquire the lock (i.e., monitors/synchronized classes). If A is a synchronized class that locks its methods internally, it would be very confusing and prone to intermittent errors to still have to manually acquire the lock whenever an object is copied or moved. Also, generic code, which doesn't know about A::mtx is unlikely to work properly.

Third attempt

One thing we can do is dispense with member initialization lists in constructors altogether

class A {
public:
  A(const A &a) {
    std::lock_guard<std::mutex> lock(a.mtx);
    i = a.i;
    i_squared = a.i_squared;
  }
  ...
};

This solution is awkward at best if any bases or members don't have default constructors, have reference type, or are const. It also seems unfair to have to pay an efficiency penalty (for constructing and assigning separately) just because there is no place to put the lock. In practice, I also suspect intermittent errors will creep into large code bases as programmers carelessly add a base or member initializer to the constructor. Finally, it just isn't very satisfying to have to just discard core parts of constructor syntax just because your class is synchronized.

Fourth attempt

Anthony Williams has suggested implementing serialized classes using a wrapper class like:

struct PrivateBaseForA
{
     int i;
     int i_squared;
};

class A: private PrivateBaseForA
{
   mutable std::mutex mtx;
public:
   A(int _i = 0) { set(_i); }
   void set(int _i) {
     std::lock_guard<std::mutex> lock(mtx);
     i = _i;
     i_squared = _i*_i;
   }
   A(const A& other):
     PrivateBaseForA((std::lock_guard<std::mutex>(other.mtx),other))
   {}
};

Anthony makes slick use of double-parens to use the comma operator. If you wanted to avoid this, you could have PrivateBaseForA's constructor take a lock.

Again, this is not yet a very satisfying solution because writing a wrapper class for every synchronized class just to get a properly locked copy constructor is clumsy and intrusive.

Finally, the C++11 approach

Fortunately, C++11 offers a nice solution that really illustrates how beautifully and powerfully the features of C++11 work together. C++11 supports forwarding one constructor to another, which gives us an opportunity to grab the mutex before any copying or moving takes place:

class A {
private:
  A(const A &a, const std::lock_guard<std::mutex> &)
   : i(a.i), i_squared(a.i_squared) {}
public:
  A(const A &a) : A(a, std::lock_guard<std::mutex>(a.mtx)) {}
  ...
};

This solution locks the entire constructor, protects against races resulting from forgetting the manual lock, works with generic code, and doesn't require the creation of artificial wrapper classes.

While I think this is clearly the preferred solution, it is not perfect. To begin with, it is more obscure and guru-like than I would wish for such a common situation. Secondly, constructor forwarding is not yet implemented by any major C++ compiler (although the recently approved standard should change that soon). Finally, we lose the benefit of compiler generated copy constructors. If we added an i_cubed field to A that also needed to be kept consistent with i, we might forget to update the private constructor. Perhaps this will be a further opportunity for the next C++ standard (C++1y?). In the meantime, C++11 provides a powerful new solution to the everyday problem of writing thread-safe copy and move constructors.

One final note is to mention that although this article focused on copy constructors, everything applies equally to move constructors. Indeed, any constructor that needs to acquire any lock whatsoever (e.g., a database lock) for its entire duration can apply these techniques.

Posted by Anthony Williams
[/ threading /] permanent link
Tags: multithreading, copying

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

What is wanted instead is a way of encapsulating the locking, so that the loop logic is simple, and yet the lock logic is also clear.

Here is the original code from the blog post:

lock_acquire(lock);
while(check_condition()){
  lock_release(lock);
  //do any actual work in the iteration - Thanks to Caleb for this comment
  lock_acquire(lock);
}

lock_release(lock);

The implication here is that check_condition() must be called with the lock held, but the lock need not be held for the actual iteration work. The code thus acquires and releases the mutex in two places, which is unnecessary duplication, and a potential source of errors — if the loop exits early then the lock may be released twice, for example.

Rather than moving the condition check into the loop to avoid this duplication, a better solution is to move the lock acquisition and release into the condition check:

bool atomic_check_condition()
{
  lock_acquire(lock);
  bool result=check_condition();
  lock_release(lock);
  return result;
}

while(atomic_check_condition()){
  //do any actual work in the iteration - Thanks to Caleb for this comment
}

This gives us the best of both worlds: the lock is now held only across the check_condition() call, but the logic of the while loop is still clear.

If you're programming in C++, then the C++0x library allows us to make atomic_check_condition() even simpler by using lock_guard as in the code below, but extracting the function is always an improvement.

bool atomic_check_condition()
{
  std::lock_guard<mutex_type> guard(lock);
  return check_condition();
}

Posted by Anthony Williams
[/ threading /] permanent link
Tags: multithreading, concurrency, locks

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter

This release thus greatly improves the portability of the library. You can now write code using just::thread that will work across Windows, Linux and MacOSX. With gcc 4.5 support across all 3 platforms, you can take advantage of the extensive C++0x language support from that compiler too, including lambda functions, rvalue references and variadic templates.

Get your copy now and add portability to your multithreaded programs.

Posted by Anthony Williams
[/ news /] permanent link
Tags: just::thread, cplusplus, multithreading, gcc, windows, macosx

| Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

Follow me on Twitter