2

I have more of a conceptual question. Assume one program running two threads. Both threads are running loops all the time. One thread is responsible for streaming data and the other thread is responsible for receiving the file that the first thread has to stream. So the file transfer thread is loops to receive the data which it writes to a file and the streaming thread reads that data from that file as it needs it and streams it.

The problem I see here is how to avoid starvation when the file transfer is taking too much CPU cycles for it's own and thus making the streaming thread lag?

How would I be able to share the CPU effectively between those two threads knowing that the streamer streams data far slower than the file transfer receives it.

I thank you for your advice.

Helder AC
  • 376
  • 1
  • 5
  • 17
  • Why are you communicating via a file? Why not just use a `pipe()`? – chrisaycock Apr 18 '12 at 13:20
  • Because the received data can need to be streamed later on again an that would imply a new file transfer. That way the file is only transferred once as for the next stream it would already be present. – Helder AC Apr 18 '12 at 13:22
  • How much data are we talking about here? Is this something you can just store in memory? – chrisaycock Apr 18 '12 at 13:26
  • Video files. HD quality. But that isn't the point. The problem is how to maybe make one loop give the other loop priority as the file transfer loop transfers data much faster than the streaming loop. – Helder AC Apr 18 '12 at 13:29
  • This is the _exact example_ that was given as application for the tee/splice/vmsplice mechanism back in 2006. `splice` from a socket into the pipe, `tee` into another pipe, `vmsplice` the first to your consumer process, and `splice` the second to disk for later. Now if only it was better documented and not broken at odd ends, this would be just perfect. Though I think the broken ends (failing to notify when buffers can be reused) don't matter when data goes in this direction... – Damon Apr 18 '12 at 15:44

2 Answers2

2

Quite often this kind of problems are solved by using somekind of flow control:

Block the sender when the receiver is busy.

This cause also problems: If your program must be able to fast forward (seek forward), then this is not good idea.

In your case, you could block the file transfer thread when there is more than 2MB unstreamed data in the file. And resume it when there is less than 1MB unstreamed data.

SKi
  • 8,007
  • 2
  • 26
  • 57
0

See if pthread_setschedparam() helps you balance out the threads' usage of the CPU

From man page of pthread_setschedparam, you can change the thread priorities.

   pthread_setschedparam(pthread_t thread, int policy,
                         const struct sched_param *param);

       struct sched_param {
           int sched_priority;     /* Scheduling priority */
       };

   As can be seen, only one scheduling parameter is supported.  For details of
   the permitted ranges for scheduling priorities in each scheduling policy, see
   sched_setscheduler(2).

Also,

the file transfer is taking too much CPU cycles for it's own

If you read this SO post, it seems to suggest that changing thread priorities may not help. Because the reason the file transfer thread is consuming more CPU cycles is that it needs it. But in your case, you are OK if the file transfering is slowed down as the streamer thread cannot compete anyways! Hence I suggested you to change priorities and deprive file transfer thread of some cycles even if needs it

Community
  • 1
  • 1
Pavan Manjunath
  • 27,404
  • 12
  • 99
  • 125