Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147890 > unrolled thread
| Started by | Frederick Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| First post | 2019-11-10 06:12 -0800 |
| Last post | 2019-11-10 15:03 -0800 |
| Articles | 6 — 6 participants |
Back to article view | Back to comp.lang.c
[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
| From | Frederick Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2019-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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-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]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-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]
| From | Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> |
|---|---|
| Date | 2019-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]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2019-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]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-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