Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #147890 > unrolled thread

[Linux] Global named interprocess mutex

Started byFrederick Gotham <cauldwell.thomas@gmail.com>
First post2019-11-10 06:12 -0800
Last post2019-11-10 15:03 -0800
Articles 6 — 6 participants

Back to article view | Back to comp.lang.c


Contents

  [Linux] Global named interprocess mutex Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-11-10 06:12 -0800
    Re: [Linux] Global named interprocess mutex Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 17:51 +0000
      Re: [Linux] Global named interprocess mutex gazelle@shell.xmission.com (Kenny McCormack) - 2019-11-10 21:16 +0000
        Re: [Linux] Global named interprocess mutex Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2019-11-10 23:00 +0100
    Re: [Linux] Global named interprocess mutex nobody@example.org (Scott) - 2019-11-10 17:54 +0000
    Re: [Linux] Global named interprocess mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-10 15:03 -0800

#147890 — [Linux] Global named interprocess mutex

FromFrederick Gotham <cauldwell.thomas@gmail.com>
Date2019-11-10 06:12 -0800
Subject[Linux] Global named interprocess mutex
Message-ID<18f48b11-ecf6-4340-af89-c98cec9eb6ab@googlegroups.com>
I have a piece of C code in Linux that uses a piece of hardware (/dev/caterpillar0). The hardware device does not support simultaneous accesses -- you can't have two threads (or two processes) using it at the same time.

About half a dozen processes need to use this piece of hardware near-simultaneously, and some of these processes are multi-threaded, so I am creating a minimalistic library to achieve this and it will be made available both as a static library (.a) and dynamic library (.so).

If I was doing this in MS-Windows, I'd just create a globally named mutex:

    HANDLE hMtx = CreateMutex( NULL, TRUE, "hardware_caterpillar0_lock"));

At the moment in Linux, I am creating a share memory object and then putting a pthread mutex inside it, and then using the pthread API to lock and unlock it. Here is the code I'm using for this interprocess mutex:

https://gist.github.com/yamnikov-oleg/abf61cf96b4867cbf72d

This interprocess mutex is actually quite clean and works quite well, but I'm able to break everything by doing this:
If I get one of the processes to perform a time-consuming operation (e.g. 6 seconds), and if I hit Ctrl + C on this process when it's doing this, then it kills the process. . . and my global mutex remains locked! So now nobody can use the hardware!

Before I started using this shared mutex, I was just creating a file and using the Linux function "flock" to lock it, but the problem with this is that 'flock' gets a lock for the current process (not the current thread) which means that it won't stop simultaneous accesses for multiple threads of the same process.

How can I get a global interprocess mutex in Linux that will release the lock if the process dies? (Even better if it will release the lock when the thread dies).

[toc] | [next] | [standalone]


#147917

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2019-11-10 17:51 +0000
Message-ID<87pnhz1uye.fsf@bsb.me.uk>
In reply to#147890
Frederick Gotham <cauldwell.thomas@gmail.com> writes:

> How can I get a global interprocess mutex in Linux that will release
> the lock if the process dies? (Even better if it will release the lock
> when the thread dies).

You will get much more reliable answer somewhere like
comp.unix.programmer.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]


#147927

Fromgazelle@shell.xmission.com (Kenny McCormack)
Date2019-11-10 21:16 +0000
Message-ID<qq9ump$3gp$1@news.xmission.com>
In reply to#147917
In article <87pnhz1uye.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>Frederick Gotham <cauldwell.thomas@gmail.com> writes:
>
>> How can I get a global interprocess mutex in Linux that will release
>> the lock if the process dies? (Even better if it will release the lock
>> when the thread dies).
>
>You will get much more reliable answer somewhere like
>comp.unix.programmer.

Are you saying that the residents of comp.lang.c are stooopid?

-- 
Modern Conservative:  Someone who  can take time  out from  flashing her
wedding ring around and bragging about  her honeymoon to complain that a
fellow secretary  who keeps a picture  of her girlfriend on  her desk is
"flauting her sexuality" and "forcing her lifestyle down our throats".

[toc] | [prev] | [next] | [standalone]


#147928

FromSjouke Burry <burrynulnulfour@ppllaanneett.nnll>
Date2019-11-10 23:00 +0100
Message-ID<5dc88875$0$1449$e4fe514c@textnews.kpn.nl>
In reply to#147927
On 10.11.19 22:16, Kenny McCormack wrote:
> In article <87pnhz1uye.fsf@bsb.me.uk>,
> Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>> Frederick Gotham <cauldwell.thomas@gmail.com> writes:
>>
>>> How can I get a global interprocess mutex in Linux that will release
>>> the lock if the process dies? (Even better if it will release the lock
>>> when the thread dies).
>>
>> You will get much more reliable answer somewhere like
>> comp.unix.programmer.
>
> Are you saying that the residents of comp.lang.c are stooopid?
>
Only about 60 percent .

[toc] | [prev] | [next] | [standalone]


#147918

Fromnobody@example.org (Scott)
Date2019-11-10 17:54 +0000
Message-ID<5dc84e74.622161704@core>
In reply to#147890
On Sun, 10 Nov 2019 06:12:34 -0800 (PST), Frederick Gotham
<cauldwell.thomas@gmail.com> wrote:

>This interprocess mutex is actually quite clean and works quite well, but I=
>'m able to break everything by doing this:
>If I get one of the processes to perform a time-consuming operation (e.g. 6=
> seconds), and if I hit Ctrl + C on this process when it's doing this, then=
> it kills the process. . . and my global mutex remains locked! So now nobod=
>y can use the hardware!

Sorry if I'm belaboring the obvious, but are you attempting to catch
the interrupt signal so that you can end the process cleanly?

[toc] | [prev] | [next] | [standalone]


#147930

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2019-11-10 15:03 -0800
Message-ID<qqa507$105n$2@gioia.aioe.org>
In reply to#147890
On 11/10/2019 6:12 AM, Frederick Gotham wrote:
> I have a piece of C code in Linux that uses a piece of hardware (/dev/caterpillar0). The hardware device does not support simultaneous accesses -- you can't have two threads (or two processes) using it at the same time.
> 
> About half a dozen processes need to use this piece of hardware near-simultaneously, and some of these processes are multi-threaded, so I am creating a minimalistic library to achieve this and it will be made available both as a static library (.a) and dynamic library (.so).
> 
> If I was doing this in MS-Windows, I'd just create a globally named mutex:
> 
>      HANDLE hMtx = CreateMutex( NULL, TRUE, "hardware_caterpillar0_lock"));
> 
> At the moment in Linux, I am creating a share memory object and then putting a pthread mutex inside it, and then using the pthread API to lock and unlock it. Here is the code I'm using for this interprocess mutex:
> 
> https://gist.github.com/yamnikov-oleg/abf61cf96b4867cbf72d
> 
> This interprocess mutex is actually quite clean and works quite well, but I'm able to break everything by doing this:
> If I get one of the processes to perform a time-consuming operation (e.g. 6 seconds), and if I hit Ctrl + C on this process when it's doing this, then it kills the process. . . and my global mutex remains locked! So now nobody can use the hardware!
> 
> Before I started using this shared mutex, I was just creating a file and using the Linux function "flock" to lock it, but the problem with this is that 'flock' gets a lock for the current process (not the current thread) which means that it won't stop simultaneous accesses for multiple threads of the same process.
> 
> How can I get a global interprocess mutex in Linux that will release the lock if the process dies? (Even better if it will release the lock when the thread dies).
> 

Make sure its robust!

https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getrobust.html

If multiple processes are waiting on this, well, the robust attribute 
works well. EOWNERDEAD is akin to WAIT_ABANDONED over on win...

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.c


csiph-web