Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

OK, I was pondering this today, and I've come to ask for completely subjective and bias opinions on it. Paradoxically, despite this, I don't think it's flame-war fodder either. I think there is room for perfectly civilized conversation -- It's hardly Vim vs Emacs.

I've used a lot of concurrency abstractions, specifically those built on top of threads. There's a big trend among them, whether it be message-passing, immutable-by-default, or thread-local-by-default or other ones.

The trend is that they're all reversing the idea of threads by making data sharing explicit rather than implicit. That is, all data is not shared unless otherwise specified, which is the opposite of traditional threading found in languages like Java. (I know Java supports its own higher-level concurrency abstractions though.) For example, you explicitly pass messages. You explicitly state which variables are thread-local. You explicitly state which variables are mutable. These are just a few examples found in some languages.

I thought this easy style of concurrency was a modern concept. I was mistaken. I started playing around with UNIX toys like fork() and pipe() recently, and I was shocked to discover that effortless, explicit concurrency mechanisms have been around since the start of UNIX.

There's something a little strange about realizing that C + UNIX from the '70s makes concurrency far easier than many modern trendy threading mechanisms.

So, here's what I'm wondering... are these modern thread abstractions simply trying to emulate UNIX-style processes on top of threads, with all of their explicitness and not-shared-by-default traits? I know that some mechanisms like STM offer things like DB-style transactions which is genuinely a modern and innovative solution for concurrency, but most just seem like new ways of doing what UNIX coders were doing a long while back.

Just to say, I'm not a UNIX fanboy, not by any stretch of imagination. I'm aware that processes are far slower than threads to initialize on many platforms, but I'm talking about this from a conceptual basis.

share|improve this question

migrated from stackoverflow.com Jul 18 '11 at 5:23

This question came from our site for professional and enthusiast programmers.

    
Not a bad question but its problem is: "I think there is room for [...] conversation". –  cnicutar Jul 17 '11 at 15:51
    
I added that so it wasn't closed straight away as being subjective/opinionated :) I'm genuinely interested to hear people's thoughts on this... –  Louis Jul 17 '11 at 15:54
    
good question. I think you're missing a larger audience for the question by leaving out a programming language tag (although I understand why you do that). You might get some additional feedback by including a tag like performance, testing, or bench-marking. There might be other tags that I'm not aware of that would broaden your responses (anyone?). Good luck! –  shellter Jul 17 '11 at 16:47
    
i would recommend removing the unix tag as your question clearly is not restricted to the unix domain. many people have specific operating systems in their ignore-tags (like me with OS-X). –  eznme Jul 17 '11 at 17:27
    
I think it is more likely that concurrency abstractions are "emulating" (more precisely, are based on) Communicating sequential processes theory –  gnat Feb 2 '12 at 17:11
add comment

2 Answers

up vote 1 down vote accepted

Good observation, there is definitely a trend towards explicit sharing (whether through functional languages or convention). The comment about processes being slower i would adapt a little: they are more heavy-weight, meaning that they are not slower executing in raw performance but every switch between them takes a lot longer than switching between threads. You already recognized that there are some other forms of concurrency and recognize STM. I would only add that there is (in addition to explicit sharing and STM) there is also a growing trend towards thread pooling (task parallel; assign tasks to worker-threads that were started beforehand and recycle them): Definitely the way to go performance-wise and curiously a different approach to explicit sharing because the pooled threads are typically all in one process.

share|improve this answer
    
I altered the performance line to suit what you said. Interestingly, I use ProcessPool in Python sometimes, which is like thread pooling, except it's a pool of processes, not threads. Even on Windows it seems to work smoothly. Then again I haven't exactly been straining it too much. I imagine that process pools are a neat way of doing concurrency in languages with runtimes that haven't a hope in hell of being multithreaded any time soon (cough GIL cough). –  Louis Jul 17 '11 at 18:59
    
It's strange that a thread pool often uses one process though -- I would've thought they would have split it across as many processes as there are CPU cores. –  Louis Jul 17 '11 at 18:59
1  
@Louis: each thread can run in a different core. –  ninjalj Jul 17 '11 at 19:55
    
@ninjalj: Sorry, a bit of a brain-dead moment from me there. I guess I was still unconsciously thinking about process pools. –  Louis Jul 17 '11 at 20:07
    
Given that this answer gives tons of info, I'm going to mark it as accepted. Stating an answer is 'accepted' in a subjective context feels a bit weird, but I feel it's justified :) –  Louis Jul 17 '11 at 21:59
show 1 more comment

I think it's a less a matter of X emulating Y, than of trying to find a balance.

Completely separate processes keep life relatively simple. They make it fairly easy to build things like pipelines of processes that take at least some advantage of multiple processors. There are some pretty obvious downsides as well though -- particularly lack of flexibility, and quite a bit of overhead.

A single process with multiple threads of execution sharing essentially all resources essentially reverses those: lower overhead and lots of flexibility, at the expense of being more difficult to design and/or keep stable.

For the most part, what's happening is that people are working at finding some middle ground that provides nearly the flexibility and speed of threads, with the simpler design and more stable result of separate processes (and, I think they're largely succeeding, to at least some degree).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.