Sean Kelly Wrote: > I considered this as well, but it imposes limitations that aren't > present with the current approach. It's possible to have more than one > condition associated with a particular mutex, for example, and to plug > in a shared mutex for interprocess synchronization using 'synchronized'.
That's a good point, I haven't come across such cases yet. I could be solved using a ChainedMonitor wrapper, but that would still require explicit initialization. > They could always be added to a project-specific base class. The > additional memory allocations are still an issue I suppose, but even > normal monitors are allocated on the heap, even if it is via malloc. That's also true, but this still requires explicitly setting the base class, Object is set as the base class implicitly. The issue with the alloc/free memory allocations is tracking the monitors so they get freed, garbage collection is automatic. I haven't seen benchmarks comparing alloc/free to D's new, but I bet D wins. > So the monitor struct is still dynamically allocated, correct? Yes, lazily allocated on the garbage collected heap, the only monitor using alloc is the one needed to bootstrap the memory manager. I used to maintain a freelist of monitors but I dropped the code in favor of centralizing memory to the GC which already maintains freelists. I added pool caching to freelist entries to speed it up a lot, all allocations have at least 16 bytes anyways so there's room to cache data. The overhead of setting a pool pointer on a freelist entry is much smaller than querying the pool after reallocating that entry. I've also centralized all the D ABI which uses memory routines into the manager itself to greatly reduce the overhead. I haven't looked at the state of the GC as of now, but if you're interested in seeing my changes I could email you the file, although it's really a different beast almost entirely.
