Свершилось! Я запустил сайт, посвященный lock-free, wait-free и просто масштабируемым алгоритмым синхронизации, многопоточности, параллельным вычислениям, многоядерныи процессорам, масштабируемой архитектуре программных систем, concurrency, паттернам и анти-паттернам, технологиям и библиотекам многопоточности, сопутствующему инструментарию и связанным темам:
It finally happened! I've launched a new web-site devoted to lock-free, wait-free and just scalable synchronization algorithms, multicore, concurrency, parallel computations, scalability-oriented architecture, patterns and anti-patterns, threading technologies and libraries and related topics.
Welcome to 1024cores!
A week ago I started telling about a couple of new helpful features in the TBB 3.0 Update 4 task scheduler, and we talked about the support for processor groups – an extension of Win32 API available in 64-bit edition of Windows 7. The main purpose of processor groups is to extend Win32 capabilities to allow applications work with more than 64 logical CPUs.
Though I wrote my previous TBB task scheduler blog just a few days after TBB 3.0 Update 4 had been released, I ignored that remarkable event, and instead delved into more than two year old past. So today I’m going to redeem that slight, and talk about a couple of small but quite useful improvements in the TBB scheduler behavior made in the aforementioned update.
Though Intel® Threading Building Blocks 3.0 Update 4 that introduces a concept of Community Preview feature has just been released, my today's blog will be about something that happened quite long time ago. One of the recent posts on the TBB forum attracted my attention to the issue of information rapidly becoming obsolete.
Master threads isolation described in the first part of the blog was not the only change in the TBB 3.0 scheduler ameliorating composability of the code parallelized with TBB. Another tightening in the scheduler guarantees improves a popular usage model described in the TBB Reference Manual as “Letting main thread work while child tasks run”. Here is a short example of what it looks like:
This is the first of two blogs where I’m going to describe some of the problems that users of TBB 2.2 and earlier came across, and the changes in task scheduler behavior made in TBB 3.0 release in order to solve them. In this part we’ll talk about issues caused by the lack of master threads isolation from each other inside TBB task scheduler. But first off, let me share with you a little of the background considerations.
Parallel Minimum Spanning Tree Algorithm
|Article / White paper||
In my previous post I've tried to explain why TBB containers are so different from the STL ones, and claimed “efficiency” and “performance” considerations to be important reasons. For the starter let me to clarify what exactly did I mean when I talked about them.