The notion of memory-mapped files (mmap on POSIX) is central to how MongoDB works. It doesn't really manage its own writes or buffers. They just update data structures in memory and let the kernel figure out how to map that to disk. However, IIRC they're forcing it to write dirty pages every 10 seconds by default.
Thus I don't see how's that related to locking. My understanding is that the reason they still use a global lock are:
a) They're young and haven't gotten around implementing this yet.
b) Since writes are fast, this hasn't been as big of an issue as people might expect (it was for us, though)
And everything works as expected as long as you're fine with your writes being asynchronous. But once you call getLastError() requesting your writes to go through after every insert, then you start seeing the global lock bite.
The global lock is something that will always exist with their architecture. It isn't a feature to implement, it's a total redesign and rethinking of the fundamentals. Their much-vaunted in-place, memory-mapped I/O architecture becomes useless because concurrency means using lock-free data structures. MyISAM in MySQL locks the entire table because it does in-place updates. Row locks can't just be added into MyISAM. It'd be such a redesign to add it, it'd end up being something much more like InnoDB than MyISAM. 10gen would have to eat an awful lot of their own words if they decided to go that route.
Thus I don't see how's that related to locking. My understanding is that the reason they still use a global lock are:
a) They're young and haven't gotten around implementing this yet.
b) Since writes are fast, this hasn't been as big of an issue as people might expect (it was for us, though)
And everything works as expected as long as you're fine with your writes being asynchronous. But once you call getLastError() requesting your writes to go through after every insert, then you start seeing the global lock bite.