2

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?

Community
  • 1
  • 1
Chris K
  • 11,996
  • 7
  • 37
  • 65

2 Answers2

1

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
  • 181,030
  • 38
  • 327
  • 365
  • 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 K Jun 10 '10 at 00:13
  • 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 Jun 10 '10 at 08:27
1

Per-thread per-page memory protection can be used to efficiently implement parallel garbage collection.

The problem to be solved is that in order to collect a region of memory, the garbage collector needs exclusive access to that region, otherwise other threads (so-called "mutator" threads) would be able to read and write objects that are not in a consistent state (for example, halfway through being copied from oldspace to newspace).

With per-thread memory protection, the garbage collector can control access to the region of memory so that only the collector thread can access it; attempts by other threads to access the region of memory will result in segmentation faults that can be handled by the collector (for example, by blocking the thread until the collector is finished with that region).

Gareth Rees
  • 64,967
  • 9
  • 133
  • 163