Finalized the "mutex" code that avoids updating the same buffer from

the RX and TX thread at the same time.

diff --git a/new_protocol.c b/new_protocol.c
index 454dc30aea3e9586a98c931078746591be0a7e1c..7120d31fa7a3c064811963709c9b7dc50111f01c 100644 (file)
--- a/new_protocol.c
+++ b/new_protocol.c
@@ -1955,6 +1955,32 @@ static void process_mic_data(int bytes) {
   }
 }
 
+//
+// Pure DL1YCF paranoia:
+//
+// Note that new_protocol_cw_audio_samples() is called by the TX thread, while
+// new_protocol_audio_samples() is called by the RX thread.
+//
+// To make this bullet-proof, we need a mutex to ensure that only one of these
+// two functions is active at a given time.
+//
+// The problem is that upon a RX/TX transition, both functions may be called at
+// the same time, and the status if isTransmitting() may be changed at a moment
+// such that *both* functions proceed.
+//
+// So in 99% if the cases, the check on isTransmitting() controls that only one
+// of the two functions becomes active, but at the moment of a RX/TX transition
+// this may fail.
+//
+// The same problem occured in the audio modules (audio_write vs. cw_audio_write)
+// and has been resolved with a mutex, and this we now also do here using
+// audio_mutex.
+//
+// Note that in almost all cases, no "blocking" occures, such that the lock/unlock
+// should cost only few CPU cycles. This may be different on systems with several
+// CPU sockets if "locking" the mutex causes cache in-coherency.
+//
+
 void new_protocol_cw_audio_samples(short left_audio_sample,short right_audio_sample) {
   int rc;
   int txmode=get_tx_mode();

diff --git a/old_protocol.c b/old_protocol.c
index 498ad7d7ea9c1dc628e39161135e7919d163fc21..36887a20e6f5a4dd176df1ee69cc1df6fe5bee62 100644 (file)
--- a/old_protocol.c
+++ b/old_protocol.c
@@ -995,8 +995,40 @@ static void process_ozy_input_buffer(unsigned char  *buffer) {
   }
 }
 
+//
+// Pure DL1YCF paranoia:
+//
+// To make this bullet-proof, we need a mutex covering the next three functions
+// that are called both by the RX and TX thread, and are filling and sending the
+// output buffer.
+//
+// Note that old_protocol_iq_samples() and old_protocol_iq_samples_with_sidetone()
+// are mutually exclusive by design (the TX thread calls the latter one if doing
+// CW, the first one otherwise).
+//
+// The problem is that upon a RX/TX transition, old_protocol_audio_samples() and
+// old_protocol_iq_samples() may be called by the RX and TX thread at the same
+// time, and the status if isTransmitting() may be changed at a moment such that
+// *both* functions proceed.
+//
+// So in 99% if the cases, the check on isTransmitting() controls that only one
+// of the two functions becomes active, but at the moment of a RX/TX transition
+// this may fail.
+//
+// The same problem occured in the audio modules (audio_write vs. cw_audio_write)
+// and has been resolved with a mutex, and this we now also do here using
+// send_buffer_mutex.
+//
+// Note that in almost all cases, no "blocking" occures, such that the lock/unlock
+// should cost only few CPU cycles. This may be different on systems with several
+// CPU sockets if "locking" the mutex causes cache in-coherency.
+//
+
+static pthread_mutex_t send_buffer_mutex   = PTHREAD_MUTEX_INITIALIZER;
+
 void old_protocol_audio_samples(RECEIVER *rx,short left_audio_sample,short right_audio_sample) {
   if(!isTransmitting()) {
+    pthread_mutex_lock(&send_buffer_mutex);
     output_buffer[output_buffer_index++]=left_audio_sample>>8;
     output_buffer[output_buffer_index++]=left_audio_sample;
     output_buffer[output_buffer_index++]=right_audio_sample>>8;
@@ -1009,6 +1041,7 @@ void old_protocol_audio_samples(RECEIVER *rx,short left_audio_sample,short right
       ozy_send_buffer();
       output_buffer_index=8;
     }
+    pthread_mutex_unlock(&send_buffer_mutex);
   }
 }
 
@@ -1021,6 +1054,7 @@ void old_protocol_audio_samples(RECEIVER *rx,short left_audio_sample,short right
 //
 void old_protocol_iq_samples_with_sidetone(int isample, int qsample, int side) {
   if(isTransmitting()) {
+    pthread_mutex_lock(&send_buffer_mutex);
     output_buffer[output_buffer_index++]=side >> 8;
     output_buffer[output_buffer_index++]=side;
     output_buffer[output_buffer_index++]=side >> 8;
@@ -1033,11 +1067,13 @@ void old_protocol_iq_samples_with_sidetone(int isample, int qsample, int side) {
       ozy_send_buffer();
       output_buffer_index=8;
     }
+    pthread_mutex_unlock(&send_buffer_mutex);
   }
 }
 
 void old_protocol_iq_samples(int isample,int qsample) {
   if(isTransmitting()) {
+    pthread_mutex_lock(&send_buffer_mutex);
     output_buffer[output_buffer_index++]=0;
     output_buffer[output_buffer_index++]=0;
     output_buffer[output_buffer_index++]=0;
@@ -1050,6 +1086,7 @@ void old_protocol_iq_samples(int isample,int qsample) {
       ozy_send_buffer();
       output_buffer_index=8;
     }
+    pthread_mutex_unlock(&send_buffer_mutex);
   }
 }
 

diff --git a/portaudio.c b/portaudio.c
index c9c77dffb9b7e10adf9e7889ab5e847e99059fe5..bdbde1db16f475ecc7a232646937580a74255a46 100644 (file)
--- a/portaudio.c
+++ b/portaudio.c
@@ -421,6 +421,15 @@ void audio_close_output(RECEIVER *rx) {
 // we have to store the data such that the PA callback function
 // can access it.
 //
+//
+// Note that the check on isTransmitting() takes care that "blocking"
+// by the mutex can only occur in the moment of a RX/TX transition if
+// both audio_write() and cw_audio_write() get a "go".
+//
+// So mutex locking/unlocking should only cost few CPU cycles in
+// normal operation. This may be different on systems with several
+// CPU sockets if "locking" the mutex causes cache in-coherency.
+//
 int audio_write (RECEIVER *rx, float left, float right)
 {
   int mode=modeUSB;