views:

13

answers:

1

Okay, so we support per-process memory paging/protection today. I've been wondering for years what sort of benefit is gained by offering page-level protections to what is arguably the smallest execution unit our OSes support today: threads. This question on Software Transactional Memory brought it back to the forefront for me.

Benefits to having page-level thread-ownership

  • OS support for locking the page when accessed
  • In theory, protection against memory corruption if the OS had a mechanism to take ownership for the lifetime of a thread.

Downsides:

  • Deadlock detection with standard locking techniques is already difficult enough
  • debugger/OS support for determining page-level ownership

Any other downsides, upsides that you can see from supporting such a model?

A: 

This kind of programming model is already possible with processes and shared memory. It isn't used much, for good reason: interprocess message passing is far safer and easier to reason about.

Marcelo Cantos
Except we DO see massive use of threading - in fact it's use is growing, thanks to languages like Go. Why not offer the ability to have page-level memory protect at the thread level? What dangers will it involve? Is it really that much more overhead protection-wise? Anything than can make multithreading safer without disadvantaging it performance wise, why wouldn't you do it?
Chris Kaminski
There would be very little difference between per-thread page protection and processes with shared memory. Adding the necessary cruft to the threading model would probably make threads as expensive as processes. To reiterate, if that's what you want, it's already possible. Go is quite different; while it allows data sharing, it strongly encourages message-based concurrency, which means it has more of an Erlang-style "process" model than a threading model.
Marcelo Cantos