Michael <[EMAIL PROTECTED]> writes: > > But ordinary programmers write real-world applications with shared data > > all the time, namely database apps. > > I don't call that shared data because access to the shared data is > arbitrated by a third party - namely the database. I mean where 2 or > more people[*] hold a lock on an object and share it - specifically > the kind of thing you reference above as turning into a mess.
Ehhh, I don't see a big difference between having the shared data arbitrated by an external process with cumbersome message passing, or having it arbitrated by an in-process subroutine or even by support built into the language. If you can go for that, I think we agree on most other points. > > This is just silly, and wasteful of the > > efforts of the hardworking chip designers > Aside from the fact it's enabled millions of programmers to deal with > shared data by communicating with a database? Well, sure, but like spreadsheets, its usefulness is that it lets people get non-computationally-demanding tasks (of which there are a lot) done with relatively little effort. More demanding tasks aren't so well served by spreadsheets, and lots of them are using databases running on massively powerful and expensive computers when they could get by with lighter weight communications mechanisms and thereby get the needed performance from much cheaper hardware. That in turn would let normal folks run applications that are right now only feasible for relatively complex businesses. If you want, I can go into why this is important far beyond the nerdy realm of software geekery. > For generator based components we collapse inboxes into outboxes > which means all that's happening when someone puts a piece of data > into an outbox, they're simply saying "I'm no longer going to use > this", and the recipient can use it straight away. But either you're copying stuff between processes, or you're running in-process without multiprocessor concurrency, right? > This is traditional-lock free, > > Lately I've been reading about "software transactional memory" (STM), > I've been hearing about it as well, but not digged into it.... > If you do dig out those STM references, I'd be interested :-) They're in the post you responded to: http://lambda-the-ultimate.org/node/463 http://research.microsoft.com/users/simonpj/papers/stm/ In particular, the one about the GHCI implementation is here: http://research.microsoft.com/users/simonpj/papers/stm/lock-free-flops06.pdf The Wikipedia article is also informative: http://en.wikipedia.org/wiki/Transactional_memory -- http://mail.python.org/mailman/listinfo/python-list
