On 2014-08-13, Alec Ten Harmsel <a...@alectenharmsel.com> wrote:
> 2014-08-13 12:21 GMT-05:00 Grant Edwards <grant.b.edwa...@gmail.com>:
> Without knowing what you're doing, this sounds like a bad idea; if
> you *need* to synchronize threads, why aren't they running in the
> same process?
I'm trying to decouple different portions of a system as much as
possible. Currently, the different parts communicate via Unix domain
sockets. That works OK, but for a few of the high-frequence
operations I'm trying to find a way to eliminate the overhead that's
involved in sockets (system calls, context switches, copying data from
userspace to kernel space and back to user space).
> If it's going to be running on Linux, you can send signals through
> the kernel's signal API; specifically HUP, USR1, and USR2 might be of
> interest to you.
I may have to look into that. Unfortunately signals are a real pain
to use in a multi-threaded application: all signals get delivered to a
single thread, when then has to "distribute" them somehow to the
thread that really cares.
>> A condition variable in shared memory is the closest thing I have
>> found, and my test applications are working OK (so far). But, I'm
>> unclear on the purpose of the mutex whose address you pass to
>> pthread_cond_wait().
>
> I'm too much of a rookie to know how to do this; how are you sharing
> memory between processes?
The standard Posix way: shm_open() et al.
>> The mutex appears to be there to serialize access to some
>> user-defined variable(s) (outside the condition variable itself)
>> which I don't have. So all the mutex locking/unlocking and resultant
>> blocking of B, C, D is just wasted overhead and pointless latency.
>
> This is definitely not a task for mutexes, a boolean or signaling
> would work much better.
I'm not sure how one would use a boolean to wake up a thread.
I may have to stick with sockets when I want to block until some event
happens.
--
Grant Edwards grant.b.edwards Yow! It's a hole all the
at way to downtown Burbank!
gmail.com
