Gentoo Archives: gentoo-user

From: Grant Edwards <grant.b.edwards@×××××.com>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: OT: pthreads condition variable/mutex question
Date: Wed, 13 Aug 2014 19:23:46
Message-Id: lsgdv9$i5p$1@ger.gmane.org
In Reply to: Re: [gentoo-user] OT: pthreads condition variable/mutex question by Alec Ten Harmsel
1 On 2014-08-13, Alec Ten Harmsel <alec@××××××××××××××.com> wrote:
2 > 2014-08-13 12:21 GMT-05:00 Grant Edwards <grant.b.edwards@×××××.com>:
3
4 > Without knowing what you're doing, this sounds like a bad idea; if
5 > you *need* to synchronize threads, why aren't they running in the
6 > same process?
7
8 I'm trying to decouple different portions of a system as much as
9 possible. Currently, the different parts communicate via Unix domain
10 sockets. That works OK, but for a few of the high-frequence
11 operations I'm trying to find a way to eliminate the overhead that's
12 involved in sockets (system calls, context switches, copying data from
13 userspace to kernel space and back to user space).
14
15 > If it's going to be running on Linux, you can send signals through
16 > the kernel's signal API; specifically HUP, USR1, and USR2 might be of
17 > interest to you.
18
19 I may have to look into that. Unfortunately signals are a real pain
20 to use in a multi-threaded application: all signals get delivered to a
21 single thread, when then has to "distribute" them somehow to the
22 thread that really cares.
23
24 >> A condition variable in shared memory is the closest thing I have
25 >> found, and my test applications are working OK (so far). But, I'm
26 >> unclear on the purpose of the mutex whose address you pass to
27 >> pthread_cond_wait().
28 >
29 > I'm too much of a rookie to know how to do this; how are you sharing
30 > memory between processes?
31
32 The standard Posix way: shm_open() et al.
33
34 >> The mutex appears to be there to serialize access to some
35 >> user-defined variable(s) (outside the condition variable itself)
36 >> which I don't have. So all the mutex locking/unlocking and resultant
37 >> blocking of B, C, D is just wasted overhead and pointless latency.
38 >
39 > This is definitely not a task for mutexes, a boolean or signaling
40 > would work much better.
41
42 I'm not sure how one would use a boolean to wake up a thread.
43
44 I may have to stick with sockets when I want to block until some event
45 happens.
46
47 --
48 Grant Edwards grant.b.edwards Yow! It's a hole all the
49 at way to downtown Burbank!
50 gmail.com

Replies

Subject Author
Re: [gentoo-user] Re: OT: pthreads condition variable/mutex question Alec Ten Harmsel <alec@××××××××××××××.com>