Tanenbaum on Shared Data Structures

I just read the essay Tanenbaum-Torvalds Debate: Part II by Andy Tanenbaum. It showed up on Slashdot today, almost two years late. Tanenbaum makes a number of interesting observations on shared data structures:

Linus also made the point that shared data structures are a good idea. Here we disagree. [...] It is exceedingly hard to get this right, even with semaphores, monitors, mutexes, and all that good stuff.
My view is that you want to avoid shared data structures as much as possible. Systems should be composed of smallish modules that completely hide their internal data structures from everyone else.

2 Responses to “Tanenbaum on Shared Data Structures”

  1. Yes, agreed with that point. Better decoupling enhances safety, potential concurrency, etc, etc.

    Rgds

    Damon

  2. I think today we have a major problem with shared data structures — we have many mechanisms to manage concurrency, but they are all too hard for the poor human brain which has to use them. But a lot of research is being done on transactional memory (whether that be software transactional memory, or hardware-assisted transactional memory, or some hybrid variety). And I think, once transactional memory becomes mainstream, we’ll see a return to popularity for shared data structures, because once you have the concurrency issues solved they really are easier to program to than message-passing interfaces.

    I also think that, even when forced to use a message-passing based interface, it should be made to look like a shared data structure (ala properties in .Net), rather than having the programmer explicitly use a method-oriented approach. I think this is good, both because its easier to think in terms of direct manipulation of data structures than message passing or method calls, and it encapsulates away the issue of whether message passing or method calls are actually used as the implementation mechanism, meaning that once transactional memory becomes mainstream we can all switch from a message passing based implementation to a shared data structures one.

    A final point — the other argument for non-shared data structures is that encapsulation is useful for access control. I agree, but there are better ways to do access control than using method calls — the problem is that most current programming languages have only a very limited set of access levels (public v. private v. restricted), and lack declarative constraints on data structures. If they resolved those issues, I don’t think encapsulation would ever really be necessary.

Leave a Reply