Mono not well suited for Linux development [LWN.net]

Mono not well suited for Linux development

Posted Dec 11, 2010 14:13 UTC (Sat) by pr1268 (guest, #24648)
In reply to: Apache resigns from the Java Community Process executive committee by butlerm
Parent article: Apache resigns from the Java Community Process executive committee

Yes, Linux could/would (probably already does) implement a better threading model for .NET than Win32, but I believe the point is that since the Win32 model is already "shoe-horned" into Mono, then .NET apps on Linux are at a performance disadvantage already (correct me if I'm wrong with Mikov's point).

Aren't .NET compiled binaries actually platform-independent bytecode (like Java)? It would seem hideously difficult to push divergent threading models into the bytecode interpreter rather than in the compiled bytecode itself (just my intuition).

to post comments

Mono not well suited for Linux development

Posted Dec 12, 2010 5:54 UTC (Sun) by mikov (guest, #33179) [Link] (5 responses)

I am not an expert in Mono or .NET (far from it), but as I understand it, the problem is that .NET is a 1-to-1 mapping of the Win32 API, including ACLs, kernel locking primitives (Win32 events, mutexes and so on). It appears that the entire .NET is built on top of these primitives, which (in my opinion) leads to a fundamental mismatch.

Some of them are not easy to emulate reliably or efficiently. Look at Wine. For example in Win32 opening a file often enforces a mandatory lock on it.

So, for example, Mono ends up having to manage shared memory areas between independent processes in order to emulate the additional Win32 semantics.

By comparison Java's API is for one much simpler (no even mention of file permissions), and if anything closer in spirit to POSIX.

So, politics aside, that is a purely technical reason that Mono may not be ideal. I would love if someone more knowledgeable commented on it.

Mono not well suited for Linux development

Posted Dec 13, 2010 4:13 UTC (Mon) by ras (subscriber, #33059) [Link] (4 responses)

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.

Mono not well suited for Linux development

Posted Dec 13, 2010 16:18 UTC (Mon) by mikov (guest, #33179) [Link] (3 responses)

Shared memory usually is not an acceptable implementation technique for these kinds of things, except when used point-to-point, or between a pool of very closely related processes. If one of the processes crashes the memory is left in a inconsistent state. There nothing preventing a rogue process from writing all over it while the others are running. And so on.

Worse, how does it work if one of the process is privileged? I smell a giant security whole right there.

The only robust solution is to have central "server" process (ala Wine). I think the performance overhead and additional complexity of such a solution are obvious.

Not to mention that the benefit of mandatory locking between cooperating processes a little dubious :-)

But my bigger point was that such workarounds (not to mention potential security vulnerabilities) and the complexity they bring should not be needed and are not desirable in a Linux programming language. When developing, administering or debugging something sufficiently complex in Linux, the last thing anyone needs is an additional tangle of semi-emulated Win32 semantics.

I am not bashing Mono or other .NET re-implementations - I think it is a great product - but in my mind it is primarily a vehicle for porting Win32 .NET apps to Linux, and not really an ideal tool for Linux-only development.

Mono not well suited for Linux development

Posted Dec 16, 2010 15:57 UTC (Thu) by dgm (subscriber, #49227) [Link] (2 responses)

> I am not bashing Mono or other .NET re-implementations - I think it is a great product - but in my mind it is primarily a vehicle for porting Win32 .NET apps to Linux, and not really an ideal tool for Linux-only development.

Let the bashing to me, then. How many .NET apps have you seen ported to Linux recently?

Mono not well suited for Linux development

Posted Dec 16, 2010 18:49 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

well, if mono does what it's supposed to, there is no need to do anything for any .NET app to make it run on linux other than to run it under mono.

so you would never see any apps explicitly ported to linux, they are all implicitly ported by the mono project.

Mono not well suited for Linux development

Posted Dec 16, 2010 19:09 UTC (Thu) by mikov (guest, #33179) [Link]

I suspect many of those apps might be of the closed source "enterprise" kind - not something that many of us would necessarily see.

The first time I played with mono I was put off by something completely superficial - the output files have a ".exe" extension by default :-)