What run-time issues are present when using thread-level memory-protection/paging?

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 t开发者_如何学Gohe 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?

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.

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).