Bartosz Milewski Missing post

[Michel Fortin]

On 2009-05-30 09:36:19 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

>> While message-passing might be useful for some applications, I have a 
>> hard time seeing how it could work for others. Try split processing of 
>> a 4 Gb array over 4 processors, or implement multi-threaded access to 
>> an in-memory database. Message passing by copying all the data might 
>> happen at the very low-level, but shared memory is more the right 
>> abstraction for these cases.
> 
> Depends on what you want to do to those arrays. If concurrent writing 
> is limited (e.g. quicksort) then there's no need to copy. Then many 
> times you want to move (hand over) data from one thread to another. 
> Here something like unique would help because you can safely pass 
> pointers without worrying about subsequent contention.

If you include passing unique pointers to shared memory in your 
definition of "message passing", then yes, you can work with "message 
passing", and yes 'unique' would help a lot to ensure safety. But then 
you still need to have shared memory between threads: it's just that by 
making the pointer 'unique' we're ensuring that no more than one thread 
at a time is accessing that particular piece of data in the shared 
memory.

I'm still convinced that we should offer a good way to access shared 
mutable data. It'll have to have limits to what the language can 
enforce and I'm not sure what they should be. For instance, while I see 
a need for 'lockfree', it's footprint in language complexity seems a 
little big for a half-unsafe manual performance enhancement capability, 
so I'm undecided on that one. Implicit synchronization of shared object 
member functions seems a good idea good however. I'll be waiting a 
little more to see what Bartosz has to say about expressing object 
ownership before making other comments.


>> There's a reason why various operating systems support shared memory 
>> between different processes: sometime it's easier to deal with shared 
>> memory than messaging, even with all the data races you have to deal 
>> with.
> 
> Of course sometimes shared memory is a more natural fit. My argument is 
> that that's the rare case.

Shared memory is rare between processes, but not between threads. At 
least, in my experience.

Shared memory is something you want to use whenever you can't afford 
copying data. Message passing is often implemented using shared memory, 
especially when between threads. That said, sometime you don't have the 
choice, you need to copy the data (to the GPU or to somewhere else on 
the network).

Also, shared memory is something you want for storage systems you want 
to be accessible concurently by many threads like a database, a cache, 
a filesystem, etc. Those are shared storage systems and message passing 
doesn't help them really much since we're talking about storage here, 
not communication. Do you realy want to say that multithreaded access 
to stored data is rare?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/