On Wednesday, August 13, 2014 08:19:19 PM Grant Edwards wrote: > On 2014-08-13, Alec Ten Harmsel <a...@alectenharmsel.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
