Bug 13611 - Mutexes cannot be created with names
Summary: Mutexes cannot be created with names
Status: RESOLVED ANSWERED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 6.4.0
Hardware: Other Other
: --- minor
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-07-30 11:13 UTC by Dean Cleaver
Modified: 2017-03-17 18:05 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED ANSWERED

Description Dean Cleaver 2013-07-30 11:13:55 UTC
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.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2013-07-30 13:56:58 UTC
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).
Comment 2 Dean Cleaver 2013-07-30 14:05:19 UTC
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.
Comment 3 Dean Cleaver 2013-07-30 16:07:40 UTC
never mind - I've managed to switch it all to "lock" statements.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2013-08-07 06:49:48 UTC
Rodrigo, this looks like a MOBILE tweak went wrong.
Comment 5 Rodrigo Kumpera 2013-08-07 10:30:43 UTC
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.
Comment 6 Dean Cleaver 2013-08-07 10:33:06 UTC
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.
Comment 7 Rolf Bjarne Kvinge [MSFT] 2013-08-07 10:34:53 UTC
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.
Comment 8 Rodrigo Kumpera 2013-08-07 10:51:51 UTC
Martin,

Could you look into this at some point? 

Rolf/Dean,

As a workaround, use a Dictionary<String,Mutex> to support names.
Comment 9 Dean Cleaver 2013-08-07 11:05:11 UTC
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.
Comment 10 Jacob Ebey 2015-11-19 18:15:11 UTC
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.
Comment 11 Luis Roquette Valdez 2017-01-16 15:09:10 UTC
This issue is still a problem.
Are there any other options for cross application synchronisation?
This is a big problem.
Comment 12 Rolf Bjarne Kvinge [MSFT] 2017-01-16 15:18:12 UTC
@Luis, what kind of cross-application synchronization? On iOS cross-app communication is not possible due to the sandbox.
Comment 13 Luis Roquette Valdez 2017-01-17 10:21:16 UTC
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.
Comment 14 Luis Roquette Valdez 2017-01-17 10:40:56 UTC
Also, by the look if it, Monitor.TryEnter always returns true... even if it is done consecutively.
Comment 15 Luis Roquette Valdez 2017-01-17 10:44:23 UTC
Same thing for Monitor.Enter... It kinda makes it difficult to synchronise without these constructs.
Comment 16 Rolf Bjarne Kvinge [MSFT] 2017-01-17 11:32:39 UTC
@Luis, this is an Xamarin.iOS-specific bug, if you need something fixed in Xamarin.Android, please file a new bug.
Comment 17 Luis Roquette Valdez 2017-01-18 10:06:34 UTC
Very true.
Thanks for that.
Comment 18 Xavier Rigau 2017-03-15 20:41:39 UTC
This happens in xamarin.mac Mobile too
Comment 19 Jacob Ebey 2017-03-15 21:21:48 UTC
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.
Comment 20 Xavier Rigau 2017-03-16 05:51:47 UTC
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.
Comment 21 Jacob Ebey 2017-03-16 06:04:47 UTC
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.
Comment 22 Xavier Rigau 2017-03-17 18:05:31 UTC
@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.