0

I am using inter-process synchronization on C#.NET Framework using named semaphore. Here is my code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Threading;

namespace csharp_dot_net_frame
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                Semaphore semaphoreObject = new Semaphore(initialCount: 1, maximumCount: 1, name: "my_sem");
                Console.WriteLine("Waiting for semaphore");
                semaphoreObject.WaitOne();
                Console.WriteLine("Semaphore lock acquired");
                Thread.Sleep(10000);
                semaphoreObject.Release();
                Console.WriteLine("exiting.");
                Console.ReadLine();
            }
            catch(Exception e)
            {
                Console.WriteLine(e.Message);
                Console.ReadLine();
            }
        }
    }
}

When I ran two instances(processes) say P1 and P2 of the above code, where P1 runs first then P2 and kill the P1 which has acquired the semaphore without releasing the hold semaphore, then the another process P2 which was waiting for semaphore on semaphoreObject.WaitOne(); deadlocks for infinite time. I want that P2 should definitely get the chance to wait the semaphoreObject irrespective of whether P1 die or not.

The same problem was resolved on this post for UNIX C++ side using lockf, wondering if some kind of similar alternative exists in C# as well. I am newbie on C# side, can someone please help me how to resolve this issue on C#.Net.

And also please suggest me the synchronization mechanism on Win32 C++ which is free from above condition of deadlock.

Thanks.

dragon
  • 21
  • 5
  • `lockf` operates on files – you might [try the same](https://stackoverflow.com/questions/685135/open-file-in-exclusive-mode-in-c-sharp). – Aconcagua Oct 22 '21 at 12:22
  • A process is not going to signal a semaphore just because you kill it or it dies. That's not how semaphores work. – Paul Sanders Oct 22 '21 at 12:30
  • thanks @Aconcagua, Is it possible that when a process is currently reading/writing a file, then other process should wait for its turn for the same file, instead of terminating with exception: **another process is currently accessing that file**? – dragon Oct 22 '21 at 12:53
  • @dragon Maybe [this](https://stackoverflow.com/questions/1406808/wait-for-file-to-be-freed-by-process) is of interest? Hint: If you do a busy wait as proposed there, though, absolutely sleep for some ms within the loop to avoid the CPU being consumed up entirely... – Aconcagua Oct 22 '21 at 12:58
  • If willing to go down to WinAPI then [this](https://stackoverflow.com/questions/28806836/wait-for-a-file-to-be-writable) might be of interest as well. – Aconcagua Oct 22 '21 at 13:00
  • Do you actually need semaphore or maybe mutex is enough? – Evk Oct 22 '21 at 13:02
  • As much I know, mutex let allow to perform **release** operation only to that process which has performed the **wait** operation on it, so between wait and release we can access the resource. If this is correct, so yeah, mutex would also be a good option. or If my understanding over mutex is incorrect then let me know, thanks. – dragon Oct 22 '21 at 13:49
  • Did you try lock? Lock prevent dead locking of a resource. Resource can be arrays looping or file reading – Golden Lion Oct 22 '21 at 13:53
  • @dragon yes but it doesn't have any counter. One thread can enter, others wait. Why you are using semaphore in the first place? I assumed you have some use for its counter. – Evk Oct 22 '21 at 14:36

0 Answers0