Meyer, OO and concurrency

[Marc van Woerkom]

>The non-shared memory, pure copying asynchronous message 
>passing, paradigm is
>far easier to program (witness all the web applications, 
>virtually all use
>non-shared memory (ie separated processors) and pure 
>message passing (defined by RFC's))
>and very easy to understand.

More evidence that shared memory is evil:

---
2. We recently read that the fix for the Hyper-Threading 
vulnerability is considered non-trivial. Why is that?

John Baldwin: The issue found with HT is that the two 
logical CPUs on a single core share the same caches and as 
a result there are ways for one logical CPU to spy on the 
activities of the other CPU in the same core. The proposed 
fixes involve ways of guaranteeing that all of threads on 
a single core are all allowed to spy on each other. For 
example, one policy is that only threads with the same 
user ID should be allowed to run together no the same 
core. The problem is that right now FreeBSD treats logical 
CPUs as separate CPUs and schedules available threads on 
the first CPU that becomes available. It would be a bit of 
work to make the scheduler more aware of logical CPUs and 
to schedule threads with respect to UIDs, etc.

Robert N M Watson: It's worth observing that this is a 
serious vulnerability across a range of operating systems, 
not just FreeBSD. If you allow untrusted users on the same 
system as an SSH daemon, you're at risk, which affects 
everyone from desktop users, to ISPs, to military 
end-users. It's also a very hard problem to solve -- we're 
looking at it from the perspective of improving the 
scheduler, bringing in OpenSSL updates to limit timing 
attacks, and obviously we're hoping that CPU vendors take 
this opportunity to explore how to harden CPU 
architectures against this sort of attack. Because this 
vulnerability isn't just about scheduling, crypto, or 
hyper-threading, a lot of hard work will have to into a 
long term solutions. 
---

 From http://www.osnews.com/story.php?news_id=10951

Regards,
Marc