1

I'm currently having trouble using Poco threads for wave data loading, generating waveforms, and calculating beat positions. My audio thread is different to the one RTAudio uses for streaming my data so it's important that it's mutex not lock for too long as RTAudio (which needs to lock my audio mutex) can't wait for too long otherwise a buffer underun will occur...which is currently happening. It's now started to happen even when the program is idling; not being asked to load anything.

I had the idea of timing how long threads are blocked from getting the mutex and how long they are locked to find out where the problem is and printing it to the console, so this would be something like 6 printf's every frame, with a target framerate of 60 frames every seconds.

I have just noticed that if I stop printing to console, the buffer underrun will not occur when the program is idling, it looks like this is an issue I have made worse using printf so many times in a frame.

I'd like to know how this is occurring but more importantly, how can I monitor thread times if I can't use printf?

cool mr croc
  • 725
  • 1
  • 13
  • 33

1 Answers1

1

POSIX requires most standard I/O functions to be thread-safe and atomic. This means that several *printf operating on same stream will block each other. You should check documentation for OS-specific non-blocking functions if you do not want locking.

Similar question: stdout thread-safe in C on Linux?

Community
  • 1
  • 1
Revolver_Ocelot
  • 8,609
  • 3
  • 30
  • 48