Re: [Mono-dev] Mutex Bug
I guess I will be having the same problem as you. So why not just use a file in the temp folder with a unique name somehow connected with the locked resource (like company_name-product_name.lck) and just try to open it with no sharing? This together with poling should be enough. Why do you need all that cryptography? - Vlad On 3.7.2014 г. 06:32 ч., Edward Ned Harvey (mono) wrote: From: Brandon Perry [mailto:bperry.volat...@gmail.com] Do you *have* to write to the same file? Yes. Here is the situation: https://tinhatrandom.org An open source, MIT licensed class library aimed at improving crypto random available to the application developer... One of the things we need to do is this: Assuming we have collected a lot of good entropy from various entropy sources, save a good strong random seed file on disk. Later, any number of applications may be launched, potentially at the same time, which need to read write the file, mutually exclusively. The reason it needs to be one file, is because that's the whole point - If the user has already entered random keyboard input, random mouse input, and we gathered entropy from the internet, and RNGCryptoServiceProvider, and other sources, then every application launch shouldn't need to repeat that. First one does it; everyone later benefits from it. Right now, I believe, if I use FileMode.Open, FileAccess.ReadWrite, and FileShare.None, that should work cross-platform to ensure only a single process may access the file at a time. The process/thread that has the file lock can read the seed, write a new seed, and flush and close. It will work reliably, I believe, for the first process that gets there, and to prevent any subsequent processes from accessing the same seed file before it is reseeded. Any subsequent processes that fail to open the file (because another process already has it open) I think, will simply have to Sleep(1) and retry opening the file. It's a little ghetto, but it should work AFAIK. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
From: Brandon Perry [mailto:bperry.volat...@gmail.com] Does the file have to be written to in real time? Why not perform buffered writes to a memory region, then flush to disk when a satisfiable amount of entropy has been met? Oh - it's not like that. It's transactional. One time, gather a bunch of entropy, and write it to disk to create the initial file. Subsequent times, read the file from disk, and change it. It's a very fast file open / read / write operation, for the purpose of benefitting from the initial entropy gathering, but every time the file is read it must be changed. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
Hi,
mono used to support this functionality, but the code to do that was very
problematic, and it is disabled in recent mono releases.
Zoltan
On Wed, Jul 2, 2014 at 9:31 PM, Edward Ned Harvey (mono)
edward.harvey.m...@clevertrove.com wrote:
Before anything else ... Can anybody recommend a way to do interprocess
mutex?
I would like to confirm this is a bug before I go create a bug report in
bugzilla. Can anybody please confirm both (a) you get the same behavior,
and (b) it's not correct behavior?
I want to make this observation as well: The class in question is
System.Threading.Mutex. But on the mono class status pages, there seems to
be no System.Threading.Mutex. So that sounds a little suspicious to me,
but maybe it's ok? Or maybe I'm overlooking it somehow?
Here is some sample source code:
using System;
using System.Threading;
namespace FunWithMutex
{
class MainClass
{
static string mutexName;
const int numThreads = 5;
static Thread[] allThreads = new Thread[numThreads];
public static void Main(string[] args)
{
mutexName = @Global\mutex-test-erihjbnkjvwiuehrnkjcxvjhwehiu;
for (int i=0; inumThreads; i++)
{
allThreads[i] = new Thread(new ThreadStart(DoSomething));
allThreads[i].Name = Thread # + i.ToString();
allThreads[i].Start();
}
}
static void DoSomething()
{
System.Console.Error.WriteLine(Thread.CurrentThread.Name +
starting...);
using (var myMutex = new Mutex(false,mutexName))
{
myMutex.WaitOne();
try
{
System.Console.Error.WriteLine(
Thread.CurrentThread.Name + running...);
Thread.Sleep(TimeSpan.FromSeconds(5));
System.Console.Error.WriteLine(
Thread.CurrentThread.Name + finished...);
}
finally
{
myMutex.ReleaseMutex();
}
}
}
}
}
When run in windows .NET, you launch several processes that each run the
above code, and the Mutex will only allow one process to enter at a time.
When run in Mono, a single process obeys the mutex correctly, but multiple
processes that are launched concurrently, each have an apparently private
mutex, because each process will allow a single thread to enter the mutex
concurrently.
In other words, the mutex *should* provide synchronization across multiple
processes, but it doesn't. Instead, it only provides synchronization
across multiple threads within a single process.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
From: Zoltan Varga [mailto:var...@gmail.com] mono used to support this functionality, but the code to do that was very problematic, and it is disabled in recent mono releases. Thanks - So - Here's what I'm trying to do. Multiple processes want to read and modify a file, but the file must be locked by a single process at any given time. I can easily open the file with exclusive read/write lock in a single process, and that will block any other process from being able to open the file... But as soon as I close the file in the first process I want to signal the second process it's ok to try again. It seems, there is no way to signal another process? I just have to tell each process to try opening the file, and if failed, then sleep and repeat? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
You could use dbus if you don't care about windows. On Wed, Jul 2, 2014 at 3:21 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: From: Zoltan Varga [mailto:var...@gmail.com] mono used to support this functionality, but the code to do that was very problematic, and it is disabled in recent mono releases. Thanks - So - Here's what I'm trying to do. Multiple processes want to read and modify a file, but the file must be locked by a single process at any given time. I can easily open the file with exclusive read/write lock in a single process, and that will block any other process from being able to open the file... But as soon as I close the file in the first process I want to signal the second process it's ok to try again. It seems, there is no way to signal another process? I just have to tell each process to try opening the file, and if failed, then sleep and repeat? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
From: Brandon Perry [mailto:bperry.volat...@gmail.com] You could use dbus if you don't care about windows. I care about windows, linux, and mac. I gather, my options are: WCF (poorly supported in mono, right?), Remoting (which is supposed to be deprecated since WCF, right?), DBus (???) Socket (cough cough) Mutex (doesn't work on mac) Named pipes (seems not available in mono, right?) Maybe looping and polling the file isn't such a terrible solution after all. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
Do you *have* to write to the same file? I recently had to deal with a similar issue, but I decided to have each thread/process write files that matched a regex, and a coordinating process looking for files that matched the regex to read and consume. So I wrote a file like file-guid.txt for each thread/process and the parent used a FileWatcher to find new files that matched the regex. Was a bit dirty, but it worked, and I think it was relatively platform agnostic... On Wed, Jul 2, 2014 at 3:39 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: From: Brandon Perry [mailto:bperry.volat...@gmail.com] You could use dbus if you don't care about windows. I care about windows, linux, and mac. I gather, my options are: WCF (poorly supported in mono, right?), Remoting (which is supposed to be deprecated since WCF, right?), DBus (???) Socket (cough cough) Mutex (doesn't work on mac) Named pipes (seems not available in mono, right?) Maybe looping and polling the file isn't such a terrible solution after all. -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
Though now that I think about it, I seem to recall OSX having odd FileWatcher issues, but I was not targeting OSX. On Wed, Jul 2, 2014 at 3:43 PM, Brandon Perry bperry.volat...@gmail.com wrote: Do you *have* to write to the same file? I recently had to deal with a similar issue, but I decided to have each thread/process write files that matched a regex, and a coordinating process looking for files that matched the regex to read and consume. So I wrote a file like file-guid.txt for each thread/process and the parent used a FileWatcher to find new files that matched the regex. Was a bit dirty, but it worked, and I think it was relatively platform agnostic... On Wed, Jul 2, 2014 at 3:39 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: From: Brandon Perry [mailto:bperry.volat...@gmail.com] You could use dbus if you don't care about windows. I care about windows, linux, and mac. I gather, my options are: WCF (poorly supported in mono, right?), Remoting (which is supposed to be deprecated since WCF, right?), DBus (???) Socket (cough cough) Mutex (doesn't work on mac) Named pipes (seems not available in mono, right?) Maybe looping and polling the file isn't such a terrible solution after all. -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
Chances are, you are going to need a per-platform system to achieve this. On Wed, Jul 2, 2014 at 4:39 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: From: Brandon Perry [mailto:bperry.volat...@gmail.com] You could use dbus if you don't care about windows. I care about windows, linux, and mac. I gather, my options are: WCF (poorly supported in mono, right?), Remoting (which is supposed to be deprecated since WCF, right?), DBus (???) Socket (cough cough) Mutex (doesn't work on mac) Named pipes (seems not available in mono, right?) Maybe looping and polling the file isn't such a terrible solution after all. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
From: Brandon Perry [mailto:bperry.volat...@gmail.com] Do you *have* to write to the same file? Yes. Here is the situation: https://tinhatrandom.org An open source, MIT licensed class library aimed at improving crypto random available to the application developer... One of the things we need to do is this: Assuming we have collected a lot of good entropy from various entropy sources, save a good strong random seed file on disk. Later, any number of applications may be launched, potentially at the same time, which need to read write the file, mutually exclusively. The reason it needs to be one file, is because that's the whole point - If the user has already entered random keyboard input, random mouse input, and we gathered entropy from the internet, and RNGCryptoServiceProvider, and other sources, then every application launch shouldn't need to repeat that. First one does it; everyone later benefits from it. Right now, I believe, if I use FileMode.Open, FileAccess.ReadWrite, and FileShare.None, that should work cross-platform to ensure only a single process may access the file at a time. The process/thread that has the file lock can read the seed, write a new seed, and flush and close. It will work reliably, I believe, for the first process that gets there, and to prevent any subsequent processes from accessing the same seed file before it is reseeded. Any subsequent processes that fail to open the file (because another process already has it open) I think, will simply have to Sleep(1) and retry opening the file. It's a little ghetto, but it should work AFAIK. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mutex Bug
Does the file have to be written to in real time? Why not perform buffered writes to a memory region, then flush to disk when a satisfiable amount of entropy has been met? On Wed, Jul 2, 2014 at 10:32 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: From: Brandon Perry [mailto:bperry.volat...@gmail.com] Do you *have* to write to the same file? Yes. Here is the situation: https://tinhatrandom.org An open source, MIT licensed class library aimed at improving crypto random available to the application developer... One of the things we need to do is this: Assuming we have collected a lot of good entropy from various entropy sources, save a good strong random seed file on disk. Later, any number of applications may be launched, potentially at the same time, which need to read write the file, mutually exclusively. The reason it needs to be one file, is because that's the whole point - If the user has already entered random keyboard input, random mouse input, and we gathered entropy from the internet, and RNGCryptoServiceProvider, and other sources, then every application launch shouldn't need to repeat that. First one does it; everyone later benefits from it. Right now, I believe, if I use FileMode.Open, FileAccess.ReadWrite, and FileShare.None, that should work cross-platform to ensure only a single process may access the file at a time. The process/thread that has the file lock can read the seed, write a new seed, and flush and close. It will work reliably, I believe, for the first process that gets there, and to prevent any subsequent processes from accessing the same seed file before it is reseeded. Any subsequent processes that fail to open the file (because another process already has it open) I think, will simply have to Sleep(1) and retry opening the file. It's a little ghetto, but it should work AFAIK. -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
