Re: [gentoo-user] Re: OT: pthreads condition variable/mutex question

[J. Roeleveld]

On Wednesday, August 13, 2014 08:19:19 PM Grant Edwards wrote:
> On 2014-08-13, Alec Ten Harmsel <alec@××××××××××××××.com> wrote:
> >> I may have to stick with sockets when I want to block until some event
> >> happens.
> >
> > To be clear, do you want to block or sleep/yield until an event
> > happens?
>
> I don't see the difference -- isn't that what a blocking call does:
> sleep/yield until some event happens?
>
> > I'm sorry for not being too helpful. Just one last question: Can you
> > describe what exactly your code is supposed to do, or is it something
> > that you can't talk about because it's a work thing? I don't care
> > either way, but I'm just curious because it seems you need to
> > optimize quite a bit.
>
> One process implements a communications protocol that is maintaining
> communications links with a handful of slave devices connected to
> serial ports running at baud rates up to 230400 baud (38400 is the
> most common).  There are typically one (or maybe two) hundred messages
> per second being exchanged with each slave device.  I'll call that
> process the server.

1 process (server)
Do you have seperate threads per slave device? Then each thread can handle the 
incoming messages when they arrive.

> There are other client processes that want to access the slaves and
> the inforamation being received from them. Some of the clients just
> want to do low-frequency transactions for configuration/diagnostic
> purposes, and Unix domain sockets work fine for that.

Have the client processes connect to a seperate thread for the communication. 
Then set up a shared memory between the relevant slave-device-thread and the 
client-process-thread(s)
I would create 2 different memory sets. One that is written only by the slave-
device-thread. And the other only by the client-process-thread(s)

That way, the client-process-threads can read that to get the current status.
And the slave-device can read the "commands" from the client-process-thread(s)

> Other clients may want to wake up every time a certain high frequency
> event happens.  That's where I'm trying to use condition variables.
>
> Other clients will periodically (typically once every 5-50 ms) want to
> see the most recent copy of a particular received message.  I'm
> thinking about using shared memory and rwlocks for that, but I haven't
> figured out how to deal with the case where a process aborts while
> holding a lock.

This sounds similar to an application I wrote a long time ago to deal with 
connecting a desktop application to a telecomms server dealing with all the 
phone connections in a company.

--
Joost