1

I'm working in a part of a bigger project, that has to read from a lot of FIFOs and redirect them properly, depending on the commands. To achieve this, the FIFOs are read in order, in an infinite loop.

The problem is that it consumes too much resources. I can understand that this process is always doing operations and waking up the processor, but I'd like to avoid so much overload.

  • An option is using signals, but it makes the processing a lot more chaotic, and it's difficult to avoid cutting execution while processing one of the commands.
  • Another option is using blocking read, but then I would need a process for each FIFO, because I don't know who and when will send a command.
  • Another option is sleeping, but I don't think is the best option, and only sleeping a few milliseconds is not a lot of difference (I haven't tried yet).

Do you have any other ideas to avoid so much overloading?

markmb
  • 852
  • 4
  • 12
  • 32
  • 1
    If this is on Linux you could use `nice` from the command line and `select` internally. – Paul Aug 10 '13 at 11:28
  • So are you trying to single-channel processing of multiple FIFOs into a central dispatch? It would seem to me a thread per-FIFO pulling with-blocking, pushing into a single fifo that is your centralized dispatch should suffice (or I utterly failed at understanding the problem as-described). – WhozCraig Aug 10 '13 at 11:35
  • @Paul Select seems to be very useful. Do you have any detailed example, because there is not much documentation. – markmb Aug 10 '13 at 11:41
  • @WhozCraig That's one of the ideas, but there can be a lot of FIFOs, and as the actions that have to be done are small, having so much threads can represent an inecessary lot of work. – markmb Aug 10 '13 at 11:43
  • 1
    @markmb http://linux.die.net/man/2/select and for an example http://www.gnu.org/software/libc/manual/html_node/Server-Example.html#Server-Example – Paul Aug 10 '13 at 11:44
  • @markmb select is fairly common actually. Perl has a binding to the select system call available to the Perl programmer. I'd expect other languages to implement the system call as well. – Paul Aug 10 '13 at 11:47
  • 1
    @markmb If you're opening and servicing a FIFO per-action, I can certainly see a potential resource abuse, but I would think a static number of them waiting in service-threads will consume next-to-nothing in system resources until populated, and then only until they can be emptied (moved, actually) and returning to blocking. – WhozCraig Aug 10 '13 at 11:49
  • @WhozCraig This is what superdesk proposes in his answer. A Thread pool pattern. – markmb Aug 10 '13 at 11:55

2 Answers2

1

Would a thread pool be appropriate? http://en.wikipedia.org/wiki/Thread_pool_pattern

You can have one process that constantly checks for new work. When a queue has something, then a thread can be dispatched to deal with it. When finished, that thread returns to the pool of available threads (thus the name). This model works well for dealing with many small tasks that do not have shared state.

superdesk
  • 1,162
  • 11
  • 24
  • When you say "constantly checks for new work", how do yo implement that? Using a controlled infinite loop? That's what I have, and that works, but uses a lot of resources. But really, without knowing, I'm using a very similar structure (I don't use threads, but I stop looking for new work and do the action, because actions are short). – markmb Aug 10 '13 at 11:40
  • Yes, check for new work with an infinite loop like you are already doing. The performance gain is when you dispatch a separate thread to do the work, because this thread can run in parallel to your main program (assuming that you have multiple cores). Even if not, there may still be a performance gain, if some work is I/O heavy and other is CPU heavy. – superdesk Aug 10 '13 at 11:45
0

As Paul suggested, I think the best option is to use select. The example that he gave is clear enough to understand how to use it (I couldn't understand it from the man page). This is a very useful tool, and it won't be the last time I'll use it.

markmb
  • 852
  • 4
  • 12
  • 32