   threaded code, conceptually
  (I'm a beginner to threaded coding, but I have read this)I wrote a program with all sorts of grandiose intentions.  It had all sorts of and bells, whistles.  I was very pleased with it.  Then, I found it necessary to add input from a serial communication line.  My program was already a little resource intensive, so I found some serial communication code (this) which is handled by its own thread.  This allowed me to receive input as in interrupt.  Furthermore, upon receipt of the data I could immediately save it to a file so as to ensure that it wouldn't be lost if my program crashed.As the "data" i'm receiving on this serial port is delimited text that I want to pass to my program (in addition to saving it), I first attempted to directly call my global functions with the text.  This resulted in a loss of serial data, as the global functions that process the text are computationally expensive.  I realized that because they were executed from the threaded code, they were thusly inhibiting the receipt of serial data.My solution to this was to keep a global queue of strings.  The threaded code, on receipt of data, appends it to the log and pushes it to the back of the queue.  In my main code (which has no thread code whatsoever, except for that i have to compile as multithreaded for the serial stuff), I check each iteration of the main loop if the queue has any text, and if it does then I pull off the front and pop the stack until its empty.  This allows the (relatively) computationally expensive stuff to process while not missing a single byte of data on the serial port.My question is, can you just add a thread to a program like that?  The only shared resource between the two places in the code is the queue of strings... I'm going to implement a mutex semaphore for accessing the queue, but other than that does it sound feasible?  It seems to work alright right now, but I'm getting a crash when I close the program (but only if i stop receiving serial data before i close)   
  Seems feasible enough. And like you already kinda stumbled into, you might need to look into some synchronization around startup (does your code gracefully handle receipt of serial data before the other part starts and vice versa?) and shutdown (is serial read blocking? if one dies, should the other? do they need to die in a certain order?). There's also a few other points like ensuring stuff like logging (often common between modules) is threadsafe.   ;  Damn!  I have some serious blocking going on!  I implemented the mutex semaphore method, and it goes like thisOn Serial Data Receipt:   Write Data to file   Retrieve Semaphore Access Push data into global queue 's'Main Exec Loop:   If global queue 's' is not empty Retrieve Semaphore Access    Copy data from 's' into local queue 't'  (and release access) Pass 't' to computationally expensive functionsWhat I had expected to happen was that as the data comes in it would immediately write it to the file, and then the computationally expensive functions would being operating on it.  As more data arrived, however, the functions would be interrupted and more data would be written to the file.  Then the functions would resume what they were doing...Apparently, however, the expensive functions are blocking the thread from writing the data to the file.  If I comment out everything but the write to the file, I get about 48kb.  When I leave them in and they run, I get about 2kb.  It seems as if the threading isn't even useful.I think it worked better before I added the mutex semaphore for synchronization.  But how can I ensure safe access to the global queue then?(or does my logic at least look right?  let me know also if you would think this would work)   ;  The logic looks fine at first glance; though logic won't do too-too much if there's resource starvation like you describe.   ;Threaded code?