Of course there are different strategies on how that memory is shared and particular sharing may only worsen memory consumption at the end.

The main difference between your description and Perl's threading strategy is that in addition to per-thread stack segments, Perl threads have per-thread data segments as well.

You are right that C threads have shared access to all of the process' memory and that the Perl separation is only enforced by Perl. But equally, Perl's lexical variables are "only enforced by perl" and they work quite well.

Also, I know many see those separate data segments as "just chunks of the heap", but the fact is that "the heap" is rarely a single heap in the old sense of the terms; and hasn't been for ... well nearly forever.

Although the "segments" I describe above are actually all just part of a single contiguous virtual address space -- not true segments in the 80286 sense -- if they are each allocated using separate calls to VirtualAlloc() (nmap() I think?), and some (even just a single page of) virtual address space is left unallocated between each of the "segments", then the classical fear of an unbounded loop in one thread succeeding in silently scribbling across all the "segments" cannot happen; as once the loop exceeds the bounds of the segment it started in and hits one of the unallocated (guard) pages, a 'segfault' occurs.

Thus, in most cases, with the language enforcing the allocation of variable addresses and guard pages to detect attempts to cross boundaries, multiple heaps can work very effectively to provide virtual segments that are largely enforced by the hardware without the need for the creation and manipulation of expensive Critical Sections to control access.

Indeed, with Perl thread's explicitly shared data, only the explicitly shared virtual segment needs a CritSec to synchronise access; and because the explicitly sharedness is a language level construct; most of the CritSec manipulations required for the (internal) safety of shared data can be moved internal to the code providing that construct. Some user level locking is required to protect user-level sharing; but internal level sharing is transparent and automatic.