Concurrent computing *

When we are told “There is no thread” we can easily come to an opinion that it is impossible at ALL that asynchronous operation could create thread, but it would be wrong opinion. Simple code example proves the opposite.

Those who are easy to treat the sentence as the universal rule are easy to understand. They would like to simplify the subject and to cut amount of theory they should study and remember. Besides to many it is new level of knowledge to discover there is other layer of classes to manage async-operations behavior beside the Tasks and and SynchronizationContext is only one among them.

Faced with situation when had to map STRING VALUE coming from database TO ENUM. The problem happens when value stored in database differs from enum name. And here we need a workaround to make a mapping. I will describe main points on how I was able to realise it.

Faced with the situation when calling Mono::block leads to deadlock - in debug I can just see how it stands on Unsafe::park and no more movement at all.

In one of the tasks on the project, I had to wrap the ForkJoinTask collection in CompletableFuture for asynchronous execution and building data processing pipeline chains.

Sometimes programming with mutexes gets too complicated and messy. Maybe you need to meet a new friend — the Event Loop pattern.

Project repository.
Year old article about general concepts of the project.

So you want to build a multitasking system using python? But you actually hesitate because you know you'll have to either use multitasking module, which is slow and/or somewhat inconvenient, or a more powerfull external tool like Redis or RabbitMQ or even large DBMS like MongoDB or PostgreSQL, which require some glue (i.e. very far from native python code) and apply their own restrictions on what you can do with your data. If you think «why do I need so much hassle if I just want to run few worker threads in python using the data structures I already have in my python program and using functions I've already written? I just want to run this code in threads! Oh, I wish there was no GIL in Python» — then welcome to the club.

Of course many of us can build from scratch a decent tool that would make use of multiple cores. However, having already existing working software (Pandas, Tensorflow, SciPy, etc) is always cheaper than any development of new software. But the status quo in CPython tells us one thing: you cannot remove GIL because everything is based on GIL. Although making shit into gold could require much work, the ability to alleviate the transition from slow single-threaded shit to a slow not-so-single-threaded gold-looking shit might be worth it, so you won't have to rewrite your whole system from scratch.

As Intel Threading Building Blocks (TBB) is being refreshed using new C++ standard, deprecating tbb::task interface, the need for high-level tasking interface becomes more obvious. In this article, I’m proposing yet another way of defining what a high-level parallel task programming model can look like in modern C++. I created it in 2014 and it was my last contribution to TBB project as its core developer after 9 wonderful years of working there. However, this proposal has not been used in production yet, so a new discussion might help it to be adopted.