Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Have these constructors been deliberately removed? I have been using the (bool initiallyOwned, string name) constructor for the past few years, and now it throws as "NotSupportedException". Assembly Browser confirms that "throw new NotSupportedException();" is the only code in the constructor.
I need to know urgently if this is a mistake, or whether I have to re-design my patterns to circumvent this.
This is a mistake on our part, we'll make the (bool,string) ctor work again.
Note that a named mutex doesn't make much sense on mobile platforms (and in particular not on iOS), since named mutexes are supposedly system-wide (which is not possible to do on iOS).
The fixed implementation will behave exactly like the (bool) ctor overload (i.e. ignore the name completely).
Named Mutexes still make a lot of sense in a multi-threaded app where you want to ensure that of 2 independent and isolated sections of code, only 1 executes at a time. It's not a system wide requirement, but without a named Mutex 2 isolated sections of code are harder to protect.
Ignoring the name means I do have to re-write my app.
never mind - I've managed to switch it all to "lock" statements.
Rodrigo, this looks like a MOBILE tweak went wrong.
Yup, named mutexes are not supported in mobile. This is a features that is only relevant when you want to perform IPC, which is not possible on this target.
They were supported. Why remove that support just because you don't use them?
They are useful in the same process to be able to ensure 2 things don't happen at the same time in 2 different classes.
Rodrigo, named mutexes does actually make sense within a single app too.
You can create two mutexes with the same name, which behaves as just one mutex.
Could you look into this at some point?
As a workaround, use a Dictionary<String,Mutex> to support names.
Currently I have worked around it by using static lock objects that both parts of code can access, however that doesn't allow for timeouts.
This was working perfectly in the last release, it was only 6.4 that removed the code from the constructor.
Did this ever get looked at? This is a problem that MUST be resolved as a framework written as a PCL will not be able to run on all platforms.
For example: A PCL library that is responsible for writing global settings to a stream will work on Windows, but will throw a System.NotSupportedException if it is used on Android or iOS. This should not be the case as the Mutex should still be created and named within the local scope of the application to allow for true PCL compatibility.
The above example would not work using a Dictionary<string, Mutex> as a separate instance of a desktop application will not be able access that Mutex.
This issue is still a problem.
Are there any other options for cross application synchronisation?
This is a big problem.
@Luis, what kind of cross-application synchronization? On iOS cross-app communication is not possible due to the sandbox.
Hi there Rolf,
I'm working on Android applications that write to files and sqlite databases...
Concurrency is very 'iffy'...
It is very easy to have issue writting to datasets in sqlite when there's no cross -process synchronisation.
These issues are usually solved using a named Mutex in c#, but I can see no construct for that in mono/xamarin.
I've managed to write a named mutex construct in c#, but it uses file locks and it is dependant on permissions to write to files.
I'd much rather have something that worked natively with mutual exclusion handles in the operating system like the ones in .Net do.
Also, by the look if it, Monitor.TryEnter always returns true... even if it is done consecutively.
Same thing for Monitor.Enter... It kinda makes it difficult to synchronise without these constructs.
@Luis, this is an Xamarin.iOS-specific bug, if you need something fixed in Xamarin.Android, please file a new bug.
Thanks for that.
This happens in xamarin.mac Mobile too
Calling you guys out on this on.... So much for this being fixed back in 2013 and allowing developers to bring their existing synchronization code to other platforms.
Well, sorry to open the can of worms again but I was told to switch to Xamarin.Mac Mobile because .NET 4.5 had some MSBUILD issues. Now my code throws Non-implemented exceptions. I am doing a Cocoa app and it can have multiple instances competing for the same file that the mutex is protecting. I don't see how there is a luxury to throw exceptions if there is any possibility that the target can produce Cocoa apps.
I'm guessing it wasn't fixed because it "doesn't make much sense on mobile platforms", but it's not about that. This is a core issue of not being able to share code as PCL's intend for you to do. If something isn't supported universally across targets then that construct should be removed from those subsets, not throw an unexpected exception.
@Jacob Ebey: I agree wholeheartedly. A compile error would have been faster and more informative. I *don't* want to target XM Mobile but I am forced to because a build limitation.