Hi,
I'm using a real-time thread under Windows in which I publish 10ms media samples at various 10ms periods (e.g. some at 10ms, some using two packets at 20ms periods etc). I'm trying to publish multiple streams from this real-time thread and require that there is no delay to publishing the data - i.e. that I call FooDataWriter->write() and the call completes in minimal time. However I can frequently see the call taking several (5-6) ms to complete.
My hypothesis is that my asynchronous publishing thread (as I'm using Asynchronous publish mode for all datawriters) is kicking in and taking a semaphore required by the writer before the RT thread starts. I can see that the two threads share at least one mutex in the EventJobDispatcher, so this appears possible.
Is there any way to stop this happening? I've tried using Synchronous publishing mode for the real-time topics but this doesn't seem to speed things up, and the documentation for Async mode states that write() is faster and more deterministic.
Any suggestions appreciated.
Chris
Hi,
Not sure how much I can help with your description, but here are a couple of questions:
Hope this helps in any way.
Thanks,
Juanlu
Thanks for the help.
Cheers,
Chris
Hi Chris,
Yes each Publisher has separate threads and separate Mutexes so it is advisable you separate the real-time Topic DataWriters into a separate Publisher.
Incidentally each Subscriber also has separate mutexes so it would also seem advisable to place the real-time Topic DataReaders into a separate Subscriber.
That said I do not have a good explanation for what you are seeing. Your guess sounds certainly plausible. Here are some questions that may help narrow down the causes of what you see: How much data are you writing each 10 ms cycle and how big is each message? What percentage of the CPU is being used? How many cores do you have? How is your OS scheduler configured? I read that the quantum that the Windows kernel assigns to a thread is affected by the OS configuration. Have you determined that your windows configuration supports determimistic millisecond-level context switching?
Gerardo