Przejdź do głównej zawartości

The (unpleasant) truth about concurrency

As Robert C. Martin writes in his wonderful book "Clean code", concurrency is hard. Concurrency is indeed so hard that most software developers do not know how to deal with it properly. Please don't feel offended. I myself thought I was quite good in writing concurrent programs at my first job, around the year 2000. But now I recognize I was rather lame about it back then and I'm only very very slightly better in understanding it. Honestly, the part I am really somwhat better at is the understanding of how many of concurrency aspects I still don't understand.

If you believe I am talking nonsense, let me just ask a simple question: have you  every read and understood this fundamental work about concurrent systems by C.A.R. Hoare? I think most programmers have never read it.

Is it so bad and should we all go back to a classroom and study CSP deeply? Not necessarily. I believe that most programmers (here I think of programming as a profession) do not really need profound understanding of concurrency. Unless we do some serious systems or concurrent embedded programming, this skill is really not terribly necessary, because we very often use a frameworks, application servers and such that have standard concurrency mechanisms already built in and the whole trick is to just use it. For many regular development tasks, it is really not necessary to know all odds and ends of concurrency. A proof of this is, in my opinion, simply the proliferation of CPython and Ruby MRI: these implementations use GIL and they do not offer real concurrency, even if someone who uses threads there imagines something different. And yet they are highly popular, successful and useful.

For the remaining 10% of programmers, who really have to have deep understanding of concurrency: they already know that it takes10+ years to develop profound understanding in this area.


Popularne posty z tego bloga

Unit Testing code with IO file operations (in Python)

We may often come across a piece of code that was written without Unit Tests at all. In addition, the piece of code may be dealing with IO like file writing and reading, which makes it more difficult to Unit Test it when we are trying to refactor and modify. Let's suppose the code in question looks like this:

def writeInitialsToFile(filename, name, surname):
    initials = name[0] + '.' + surname[0] + '.'
    with open(filename, 'w') as file:

def readInitials(filename):
    initials = None
    with open(filename, 'r') as file:
        initials = file.readline()
    return initials

A straightforward and bad idea would be to write a couple of Unit Tests that make use of a real file and simply test the reading and writing. Is therea a better way to test this code?

First of all, we need a way to replace the real file with something else. For both reading and writing we will now have a couple of functions, one that expects a stream fo…

Piotr's Less Obvious Advice on Google Mock: State maintenance

Google Mock provides several ways to maintain state inside mock objects. One way of implementing state maintenance is with SaveArg. Consider the following example.

We have a class Configurator, which allows a caller to set and get values of a parameter:

class Configurator

    virtual ~Configurator() {}

    virtual void setParamX(int n) = 0;
    virtual int getParamX() = 0;

And we have a class Client that calls Configurator's methods and it also has a method incParamXBy, that can be used to increase the current value of paramX by a certain value.

class Client

    Client(Configurator & cfg);
    virtual ~Client() {}

    void setParamX(int n);
    void incParamXBy(int n);
    int getParamX();


    Configurator & _cfg;

incParamXBy internally calls setParamX and getParamX on Configurator:

void Client::incParamXBy(int n)
    _cfg.setParamX(_cfg.getParamX() + n);

Let's assume that the initial value of paramX is A and that we want to increase paramX by…

Piotr's Less Obvious Advice on Google Mock: Returning new objects from a mock

Google Mock provides a way to return newly created objects from a mock method. Suppose we have a  Generator class that is supposed to generate new objects when createNewRecord method is called:

class Generator
    virtual ~Generator() {}
    virtual Record * createNewRecord() = 0;

...and suppose we want to mock this class:

class MockGenerator : public Generator
    MOCK_METHOD0(createNewRecord, Record * ());

Suppose the caller class Client has run method defined as follows:

void Client::run()
    for(int i = 0; i < 3; i++)
        rec_tab[i] = gen.createNewRecord();

We want the mock to return a pointer to a new object each time createNewRecord is called. This is how we can express this in the test code:

TEST(ClientTest, CanRun)
    MockGenerator gen;
    Client c(gen);

    EXPECT_CALL(gen, createNewRecord())
                 //this is equivalent of returning new Record(1,2,3)