Mono not well suited for Linux development

Speaking as someone who did a re-implementation for .NET's mutexes and other threading mechanisms for pnet (another Linux .NET implementation) there is no real speed penalty for them. We got it much faster than mono was at the time and it didn't look too far from native Win32, although it was hard to tell as the VM/interpreter very slow compared to Microsoft's.

But the link being referred to isn't talking about mutexes. Its talking about Windows file locking semantics. Since those semantics crosses process boundaries, perfect emulation of those semantics may involve a lot code and work, probably involving shared memory.

But nonetheless, it doesn't have to be slower than the native Win32 implementation. It looks from what you have written that you think accessing shared (mmap'ed) memory is slow. It isn't. It is just as fast as any other sort of memory. The other ingredient is some sort of memory barrier / locking mechanism. As it happens kernel provides a very fast implementation of those for user space - futexes. They were originally provided for SQL DB engines that make far larger demands on a locking subsystem than Windows file locking is ever likely to.

The Linux implementation could potentially be faster than the Win32 implementation a file locking operation under Win32 involves a system call. A user space implementation of Win32 file locking under Linux may not, because futexes don't need to go to the kernel unless there is contention over a lock.

The other assumption you make is that having a perfect and fast emulation of Windows file locking is necessary for a good Mono implementation. In theory .NET like Java is write once run everywhere. In practice, they (Microsoft) never got close. For example, the WinCE implementation of .NET made no pretence of being compatible with the Win32 implementation. If you started development with the idea it should run on both, then perhaps you had a hope although it would be hard going. Otherwise forget it. Likewise there are a 1000's of hidden incompatibilities between Mono and Microsoft's .net implementation and they ain't restricted to locking, so chances of a .Net program written exclusively for Windows running just as well under Mono are very close to 0. Writing a new .Net program so it runs under both is very possible of course, but in that case you just avoid stuff that doesn't work on both platforms, and that includes Win32 file locking semantics.

So: the file locking could run as fast on Linux as it does on Windows. But in all probably the current implementation it doesn't just run more slowly than the the Windows one, it almost certainly isn't a perfect implementation so in some cases could be said to not run at all. However there is a reason it is like that: it doesn't matter.