Slashdot Mirror

goroutines are not threads

What is this nonsense? A goroutine is a lightweight thread of execution.

light-weight processes (goroutines)

Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall. (There are other ways to do threading involving userspace scheduling but they are generally no better than using the standard syscall and typically much worse.) I appreciate the syntactic sugar and the channel concept is nice as a built in, but please, it's not magic, and Go doesn't have a monopoly on it.

Maybe somebody meant to say "goroutines are not processes". True. Processes have separate address spaces.

http://www.threadingbuildingblocks.org/ seems sane afaict.

From the FAQ - http://www.threadingbuildingblocks.org/wiki/index.php?title=Licensing:

TBB is available under the common OSS license GPL v2 with the libstdC++ Runtime Exception. This is the same license used for a variety of well-known OSS applications including MySQL, NetBeans, and the Linux kernel.

Intel Thread Building Blocks (http://www.threadingbuildingblocks.org/ is (are?) fantastic. Open source (GPL), works on any ISO-compliant C++ compiler and is fairly intuitive. It allows both high-level (parallel_for) and low level (task-based) parallelism. Particularly useful are the concurrent containers, since it saves you from reimplementing these basic structures.

GCD seems to be little more than an implementation of Intel's Thread Building Blocks adapted to Apple's platform:

http://www.threadingbuildingblocks.org/

So, in a sense, you as Linux users already have it.

This technology is very valuable to massive single-threaded application such as legacy or poorly-implemented UNIX applications. This shouldn't be necessary on the Microsoft platform, which has been fully multi-threaded as a standard practice since the 90's.

If Apple has made the technology more developer accessible, then this will be a valuable contribution to the Linux platform.

In short, Apple is giving it away because it has no proprietary value. They probably just want free labor for maintaining their fork of TBB.

We do need something to make multiple-CPU programming easier though. Threaded programming in C/C++ or similar can turn into a nightmare real quick, it's error prone and complicated.

If you want to use C++, I suggest Thread Building Blocks, which is an open-source C++ library. It is a set of reasonable primitives, including a task scheduler and some simple parallel iterators that create tasks. The task scheduling makes it mostly independent of the specific number of cores in the system, which is key. It think it is part of most Linux distributions these days. For simple data parallel computations, you can avoid thinking about threads and locks entirely, but yet it also allows provides the low-level primitives to write sophisticated highly optimized code, too.

P.S. I totally agree that Erlang is just *not* the right solution for multicore. Erlang's message passing is great for the application for which it was designed (telecommunications equipment with multiple independent line cards and such) or any such highly concurrent applications with high availability needs. It just isn't well suited for multicore programming (which just has an entirely different set of challenges such as data locality).

Problem? The development tools aren't available and research is only starting.

Nonsense. Here are a few couple of portable tools and libraries that will solve many developers problems.
http://www.threadingbuildingblocks.org/ (c++)
http://developers.sun.com/sunstudio/downloads/ssx/tha/tha_getting_started.html
Research is mature and ongoing.

Education, however, is only starting to reach the mainstream.

A year or so ago, I saw a presentation on Thread Building Blocks, which is basically an API thingie that Intel created to help with this issue. Their big announcement last year was that they've released it open-source and have committed to making it cross-platform. (It's in Intel's best interest to get people using TBB on Athlon, PPC, and other architectures, because the more software is multi-core aware, the more demand there will be for multi-core CPUs in general, which Intel seems pretty excited about.)

Along with OpenMP, try to look at Intel Threading Building Blocks http://threadingbuildingblocks.org/ It's even GPL v2

That intel figured out that 5 percent market share mattered a whole lot when it's only a two player game, and it's running close. Obviously, if intel can control the entire *NIX world, AMD is in for some hurt.

It is neither Linux nor Intel specific

http://threadingbuildingblocks.org/

Cross platform support:
* Provides a single solution for Windows*, Linux*, and Mac OS* on 32-bit and 64-bit platforms using Intel®, Microsoft, and GNU compilers.
* Supports industry-leading compilers from Intel, Microsoft and GNU.

Threading Building Blocks supports the following processors:
* Non Intel processors compatible with the above processors