Overhead of startThread()


#1

Hi,

I am using a thread to send UDP datagrams every 4 audio blocks.

- I would implement this by starting a thread every 4 audio blocks, the thread would send the datagram and exit.

- Alternatively, I could have a while loop in the run() method of the thread always running (and sleeping) in the background, which would send the datagram whenever a given flag is set.

I would prefer the first approach, unless there is any noticeable overhead in calling startThread() and exiting the thread every time.

Is there any overhead associated with startThread() ? 


#2

Yes, there's a huge overhead in starting a thread! Your second suggestion is the only possible way that'd work!


#3

..BTW you might want to try a ThreadPool and post it ThreadPoolJob objects.


#4

Thanks Jules,
though I still need something that it is somehow clocked by the audio clock with as small a jitter as possible.

I know this is EVIL in theory, but what if instead I use DatagramSocket::waitUntilReady() with a timeout of 0 INSIDE the audio thread and, only if the socket is available I use DatagramSocket::write() to write some small message (~200bytes) to the socket? Is the time taken by write() to complete deterministic, once I check in advance that the socket was ready?


#5

You need a WaitableEvent. Anything else, even a mutex, on your audio thread will cause problems.


#6

A good introduction about RT problems: ( http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing ).


#7

Thanks Jules that is what I was looking for


#8

Thanks 4321,

I am already familiar with this material, that is why I was asking if write() has some sort of deterministic behaviour or not.