Subscribe: Comments on armstrong on software: Why I don't like shared memory
http://armstrongonsoftware.blogspot.com/feeds/5913465963863651059/comments/default
Preview: Comments on armstrong on software: Why I don't like shared memory

Comments on armstrong on software: Why I don't like shared memory





Updated: 2017-11-14T22:35:21.332-08:00

 



Joe, I atually think having shared memory is a gre...

2008-10-01T08:21:00.000-07:00

Joe,
I atually think having shared memory is a great thing. But i also agree with the comment above. Especially with problem #7 A single faulty process can broadcast corrupt data to all other processes, easily invalidating their local data, as illustrated by computer viruses.

Cheers,
James



You may find it interesting that in the field of s...

2006-09-10T21:53:00.000-07:00

You may find it interesting that in the field of static analysis and code verification - shared memory is often reduced to a message passing protocol. It seems that what you really dislike is the usage of blocking. Yes, blocking is the root of many software evils, but is very common in message passing systems too. Maybe you should write a column about that?

More comments following:



re genneth's comment, "You might also point toward...

2006-09-07T18:49:00.000-07:00

re genneth's comment, "You might also point towards the recent paper that surveyed recent language trends." Can you post a link?

I believe this is the reference: http://www.info.ucl.ac.be/~pvr/bookcc.html



Just a note about the (deeply flawed) traffic ligh...

2006-09-06T22:48:00.000-07:00

Just a note about the (deeply flawed) traffic light analogy that some people seem to have missed:

The supposition that we (or a thread) might all be looking at the same traffic light overlooks the fact that only one person at a time can be looking at it (particularly in a single-processor machine). Suggesting that shared state often resolves itself to certain constants (like the



Is Mnesia a shared memory system? If you need to ...

2006-09-06T20:05:00.000-07:00

Is Mnesia a shared memory system?

If you need to find data, how do you do this (efficiently) in a non-shared memory system? Especially if it is more data than can fit on one machine (and even more if it needs to be persistent)?



Threads, processes, machines are all part of the e...

2006-09-06T08:10:00.000-07:00

Threads, processes, machines are all part of the execution of a model. They aren't the model.

Similarly, pipes, sockets, shared memory, in memory calls are also part of the execution of message passing. They aren't the model too.

For example, a bank teller waits on a queue of customers. They only do something when the queue is not empty. To me that means that each object



re Joe's comment, "Surely you need shared memory t...

2006-09-05T21:36:00.000-07:00

re Joe's comment, "Surely you need shared memory to implement a messaging system?"

Perhaps, but not necessarily. You could use sockets, for example, which would allow you to run things in parallel on a cluster as well as a SMP. Second, assuming you did use shared memory to implement the messaging system, you'd only need to get it right in one place. Get the messaging system right (or,



By the way, good article. Looking forward to many...

2006-09-05T21:34:00.000-07:00

By the way, good article. Looking forward to many more, though it's probably not necessary to use simplified analogies to explain Erlang concurrency. Most programmers seriously studying Erlang right now are most likely early adopters and real hackers capable of understanding the intracacies of the language on its own terms, or by analogy<



Joe (not Armstrong) said... "Surely you need share...

2006-09-05T16:35:00.000-07:00

Joe (not Armstrong) said...
"Surely you need shared memory to implement a messaging system?"

No; in fact shared memory systems are implemented in terms of message passing at the hardware level. That's what a cache coherence protocol does.

----
Several people mentioned the cost of message copying. Since Erlang is based on a pure-functional core language, message



I don't understand Problem 5 - it seems like a res...

2006-09-05T15:58:00.000-07:00

I don't understand Problem 5 - it seems like a restatement of what Problems 2 and 3 describe more specifically. In fact, I don't even like its wording - it seems to say that if you don't use shared memory, then tasks never have to wait for each other. That's certainly not true. Message-passing systems certainly have tasks blocked waiting for results from other tasks.

Otherwise, I agree



I do not share memory with other trafficants when ...

2006-09-05T15:12:00.000-07:00

I do not share memory with other trafficants when waiting for a traffic light - the light is not forcing us all to stop state,
it is a message (photons)!

I can ignore it and drive anyway. And ambulances are even allowed to do just that!



I have a few questions about this article. Proble...

2006-09-05T12:15:00.000-07:00

I have a few questions about this article.

Problem 3: "A typical page size might be in the range 8-64KB - with a page size of 8K you might only want to protect a single byte, but you are forced to protect a minimum of 8KBytes."

Leaving aside that on 32-bit architectures this is usually 4k, what do you mean that someone is forced to protect at least a page? I can have



Enjoyed the article; thanks. @things-like-image-p...

2006-09-05T11:29:00.000-07:00

Enjoyed the article; thanks.

@things-like-image-processing: this is obviously a case where message passing probably wouldn't be the best solution.

One of the issues discussed was the disconnect between page size and space-I-want-to-lock size; with image processing your processes will generally be working on different areas, so I don't see it as being as much of an issue.



@Ben & Joe: Seems like the salient point regardin...

2006-09-05T11:04:00.000-07:00

@Ben & Joe: Seems like the salient point regarding the traffic light is that 1), it is read-only, as far as the drivers are concerned (drivers can't change its state), and 2) it can be read by all drivers in its lane concurrently without need for message passing or non-shared-state constructs.

A better example might be the entire system of traffic lights, rather than any single one.



Most of the above problems can be avoided by the u...

2006-09-05T10:10:00.000-07:00

Most of the above problems can be avoided by the use of consensus operators, such as compare-and-swap.

You may be interested in investigating lock free data structures.

That said, lock free structures do require careful design.



No no no - Ben is wrong If I drive at a red traffi...

2006-09-05T08:20:00.000-07:00

No no no - Ben is wrong
If I drive at a red traffic light
at 7*10^4 Km/sec the red light will
appear green due to the doppler shift.

So some people will see red other green, depending upon the speed.

So there is no shared state,
eveybody has a different idea and they cannot agree.



It's funny -- in principle I agree with you, altho...

2006-09-05T07:59:00.000-07:00

It's funny -- in principle I agree with you, although, since my work tends to be more in things like embedded image processing, copying massive amounts of data doesn't seem like such a hot idea. Still, for most purposes, I'm on your side.

The thing that bugs me, and I wish you would leave out, is the attempt to justify it with weak "the world is like this" metaphors.

Things



Surely you need shared memory to implement a messa...

2006-09-05T07:35:00.000-07:00

Surely you need shared memory to implement a messaging system?

As far as I can tell you would have to allocate to each process a message queue which would have to be shared among other processes to allow message posting.

Is there some other way of doing it and if not, don't some of the mentioned evils of shared memory apply to messaging itself?



I have a question to do with memory usage and the ...

2006-09-05T07:01:00.000-07:00

I have a question to do with memory usage and the cost of memory copies.

Often processes work on huge amounts of data (e.g. image and signal processing) and it isn't feasable to copy the data from process to process.

How do we organize work done by several processes on these large chunks of data given limited memory resources?



A much better article than the last one; I think a...

2006-09-05T06:00:00.000-07:00

A much better article than the last one; I think a reasonable level to pitch things is to imagine a Java/C++ programmer who works on "enterprise" systems. Myself, a member of the choir already, isn't about to be unduly swayed. Someone who needs a metaphor to understand message passing isn't going to benefit either.

You might also point towards the recent paper that surveyed recent



This is a great article. You really convinced me h...

2006-09-05T05:28:00.000-07:00

This is a great article. You really convinced me how wrong shared memory model could be. Anyway, message passing with independent memory space fits the rule of good engineering and design: minimal mechanism and maximum functionality.

One of the important thing is: it scales!



But even with message passing you can have dead-lo...

2006-09-05T05:07:00.000-07:00

But even with message passing you can have dead-locks. Message queues can fill up and leave you in a blocked state.If you now have some interdependencies, you have a dead-lock. Been there recently.

But I still think that MP is better than shared memory, even if you have nice mechanisms like software transactional memory



Great article. I generally agree with your conclus...

2006-09-05T04:15:00.000-07:00

Great article. I generally agree with your conclusions about how awkward and error prone shared memory model is - yet your physics digression I suspect to be not adequate. Shared memory, when mapped to physisc, does not mean that we introduce two objects existing both at the same time and in the same place, because sharing memory region does not create seperate, yet coupled, views of its contents



I accept the First Law of Concurrency, that the wa...

2006-09-05T02:44:00.000-07:00

I accept the First Law of Concurrency, that the way to keep your sanity in concurrent programming is to have No Shared Data. But working against this on a distributed platform there are requirements for such things as 1) no single point of failure; 2) allocation of work to available resources; 3) aggregation of related real-time events.



There is an alternative to locking large blocks of...

2006-09-05T02:21:00.000-07:00

There is an alternative to locking large blocks of memory at a time, in suitably low-level languages - manual locking. Here you acquire a semaphore or mutex from the operating system or other reliable API that can guarantee atomic locks/unlocks. To the API itself, the lock you acquire has no particular semantics.

The locking is accomplished at a highly granular level by explicitly