I'm not convinced that SCOOP can work. The problem I see with it is that it allows for arbitrary sharing of state among concurrently executing objects. If it can be made to work then the compiler will probably have to make such conservative decisions wrto synchronization that performance will be a tiny fraction of the theoretical optimum.



Frank Hileman wrote:  If you have decided by design that all messages to the barrel modify its state, and that all messages are dependent upon the state of the barrel (ie are invalid if the barrel has been modified), you have serialized access to the barrel by design. It does not matter what form of concurrency you use, locks, message passing, transactions, it is the same problem, and is the same problem a CPU has when determining the dispatch order of instructions that write to a memory location.

No, it's not serialized by design, in fact it's (deliberately) extremely parallel by design, with the occasional rare conflict. You have tens of thousands of objects, most of which don't care one bit about that barrel, but sometimes one of them does, and even more rarely two or more of them do.
The point is that the mere infinitismal possibility of conflicts cause 100% serialization when you use message passing, whereas with transactions you can run in parallel, and deal with those rare cases of conflicts when and only when they actually occur.

If it's just the case of a single barrel you may be able to hack your own optimistic transactional memory on top of the messages (e.g. you have one message which does not block that you can use to check if you need to update the barrel, and if so you just do it again with the atomic version - that way 99.9% of the objects would just decide that they don't care about the barrel at all and leave it alone), but it gets much worse in real world scenarios. In practice you'll often have each object want read N unspecified objects from the world, and modify M other unspecified objects in the world (which may or may not overlap with the N that you read). There is no way to know up front which objects you need to read/modify, you only know the exact set of objects that was needed after the operation has occured. All this has to happen atomically, naturally, which means that with message passing you'll be forced to have a single service guarding "The World", and each object's operations on the world will be entirely serialized. It's simply impossible to do this concurrently if your world is guarded by a message process, even though the number of actual conflicts that these atomic operations have are very very low.
And again, with transactional memory, the problem simply disappears and you get near linear speedup as you add more CPU:s.

Also, I didn't "design" the problem to be difficult for message passing, it just was difficult for message passing all by itself. Sometimes the thing you're simulating just isn't suitable to message passing. You can't blame the problem because the language doesn't offer a good way of solving it!

Look, I'm the biggest FP advocate there is. I like Erlang et al. as much as the next guy (though my favourite language is Haskell), but the fact of the matter is that there are real problems that can not be solved with message passing. In my experience, most applications that are actually concurrent by nature (servers, etc.) can use message passing good effect, but when you try to speed up non-concurrent applications the instances where your problems map nicely to threads and messages start to become more rare. We can't just ignore these problems (again, Almdahl's law won't let us), we need to provide a solution for them too. That's why we need many ways of doing these things. In most cases you can be data parallel, in some cases you need task based parallelism, and in yet fewer cases you can use threads and message passing, and in fewer cases still you need transactional memory. We can't leave any of these out though, as that would disqualify the language from being considered "general purpose" w.r.t. concurrency/parallelism, IMO.

How could these message be run in parallel, if each of these message requires atomic updates? I.e I need to do "Find position of explosive barrel, if I collide with it then explod it", it's no good if someon else does this at the same time and moves the barrel after I've read the position but before I explode it! How could you possibly know that two threads who both read data from the game world (for example) will not decide to write to the same place as a result of that read? Atomic access is key, and with message passing that means the accesses get serialised.

In some cases message passing just doesn't work well at all. For example you may want 10000 objects to be able to query the same data (but only one or two of those objects of those modifies the data). Do you really want each to pass through a protocol with just a single thread "owning" that data? Sounds like a recipe for disaster w.r.t. performance to me. Transactions scale very well in situations like that (which is extremely common in practice), because each thread can do all the reading it wants to without interfering with the execution of any other threads.


EDIT: Oh, and consider the problem of granularity. Take the example of a game. You're running a thread for an AI character who wants to perform an action on the game world atomically. How do you solve that? Do you ask the World object to retrieve whatever it is the AI wants to access? In other words is the World object's service going to act as basically having one big lock on it for any atomic updates that AI characters want to do? Or do you put the implicit "lock" somewhere further down in the hierarchy (e.g. on individual objects in the world)? If so, how is this different from just having locks on the individual objects? How do you solve the problem of not knowing up front which objects you want to modify (because the set of objects you need depends on the values you find in the first couple of objects you examine)? Aren't we back in the old hornets nest of locks and condition variables again?
So basically we either have to let the toplevel object provide a transactional interface (amounting to a big implicit lock), and basically eliminate any chances of parallelism, or we go back to horribly impractical fine grained locking with all the problems that poses. In this scenario, message passing gives no improvement to us, whereas transactional memory "just works" without any synchronisation burden placed on the programmer at all!



sylvan wrote:  Frank Hileman wrote: For me, isolation via message passing sounds more interesting than transactional memory. It has proven useful for decades. Why not have both? In some cases message passing just doesn't work well at all. For example you may want 10000 objects to be able to query the same data (but only one or two of those objects of those modifies the data). Do you really want each to pass through a protocol with just a single thread "owning" that data? Sounds like a recipe for disaster w.r.t. performance to me. Transactions scale very well in situations like that (which is extremely common in practice), because each thread can do all the reading it wants to without interfering with the execution of any other threads. ...

I see what your saying, but lets analyze that.  Essentially, that is a classic ReaderWriter lock sample.  You need the sync, because you never know who the last action was, a reader or writer.  So you still need some kind of sync primitive to protect the invariants.

One may say, lets keep the message queue for writers, but let readers read properties directly. But here we have couple issues.  You still need lock to insure atomic reads (i.e non cache and non torn).  Second, you have possible coordination issues the runtime could never know and only your logic knows.  For example, your object may intentionally not be popping the queue (sort of a working blocking operation) queue until it completes work for last task - as maybe order is important or maybe is waiting on various replies.  There is all kinds of reasons order could be important and you can't reliably short circut that in general case.  So only the Object knows best.  As far as Perf goes, yes the message passing has some cost.  But so do ReaderWriters and Monitors.  When you look at the "net" performance, I think it probably is a wash or better with message passing.  Costs such as complexity and correctness proof are much less from the start.  There is many other benefits you can't get with locks or even trans memory.  You can get order symatics, self messaging, throttling, naturally async, pipelining, natural composition, loose binding, and others.

Think Juval Lowy nailed it here. Every class needs to be a service:
http://channel9.msdn.com/ShowPost.aspx?PostID=349561#349561



Frank Hileman wrote: For me, isolation via message passing sounds more interesting than transactional memory. It has proven useful for decades.

Why not have both?
In some cases message passing just doesn't work well at all. For example you may want 10000 objects to be able to query the same data (but only one or two of those objects of those modifies the data). Do you really want each to pass through a protocol with just a single thread "owning" that data? Sounds like a recipe for disaster w.r.t. performance to me. Transactions scale very well in situations like that (which is extremely common in practice), because each thread can do all the reading it wants to without interfering with the execution of any other threads.

I agree that message passing is ideal when suitable, but sometimes it just isn't. Also, while threads are sometimes excellent abstractions (even for things where you *don't* care about concurrency they may be the right model), sometimes they just suck. They basically suffer from the same problem that "goto" does: obfuscation of the structure of the program (you have to jump back and forth through messages in different threads, which one may not be known until you run the program, to understand what the program does).

Now I freely confess that I hadn't seen E (I'll look into it now) so if they give some new cool abstraction that solves all of this I'll recant my statements, but for now I'll say this: there is no one solution, we need multiple solutions to the problem of parallelism/concurrency. In my book the bara minimum is: Nested data parallelism, task-based (purely functional) parallelism, threads with messages, and threads with shared state (here's where you need transactions).



Frank Hileman wrote: The Singualrity OS proved that inter-process communication, at least, can be faster when using a higher level language, as long as strict contracts are observed. This means drivers are best not written in a language such as c++, since they are a critical part of the OS stack.

Depends. If your operating system trusts the people who are writing the drivers (as has tended to be the case in the past) then languages such as C++ and C will almost invariably be at least as fast as anything written in C# or other high-level pointerless languages.

(i also think that while the clr isnt perfect, its unfair to say that the its "severly limited")


No language disallows side effects. Haskell is full of them!

The difference is that in Haskell the side effects are contained within a pure type system. So even if you have small component somewhere that uses mutable state internally (e.g. some algorithms require mutable state!), the type system can keep track of that for you, and will refuse to let any of that mutable state "leak" out to the pure code. You can use side effects, but the compiler will force you to keep them separate from the bulk of the code (which doesn't have side effects).

 We can actually do this pretty easy with OO today.  You can derive all objects from a class that has an in and out queue and a worker thread.  Then send messages to it and it processes all messages in local scope if it wants.  However, not sure this is better then some library (i.e. ccr, pfx) that takes lambdas and does the work inside a closure.  With the ability to have nobs on the library for thread min/max, wait times, throttles, perf mon, etc. The former could be a good design for a pipeline server (i.e. sql), but I think the later is better for general work and things like joins, choice, futures, etc.  Room for both I think.