È atomico solo per come scrivi la tua coda / struttura FIFO.
Avvolgere un mutex o qualche altra forma di blocco attorno alla coda FIFO è probabilmente il modo più semplice per garantire la concorrenza e l'atomicità per l'ambiente che descrivi.
Se avremo più processi che tentano di scrivere in coda, probabilmente avrai bisogno di un gestore dedicato per la coda.
Opzione A.
Potresti configurare due aree di scrittura per la coda: la prima area è dove tutti i processi possono scrivere, sincronizzati con una sorta di schema di indicizzazione, o:
Opzione B.
Probabilmente sarebbe più pulito avere un processo dedicato per la coda che ha più thread per ricevere richieste di scrittura. La sincronizzazione sulla scrittura in coda viene quindi gestita all'interno del processo di coda FIFO stesso.
Di norma, a meno che tu non abbia la documentazione in mano che dichiara l'operazione Foo come thread-safe / atomic / qualunque, allora supponi che non sia sicuro. Avere "letto da qualche parte ..." non lo taglierà quando hai condizioni di gara e i dati nella tua coda sono stati distrutti dalle scritture simultanee.
Opzione C.
Usa la struttura Pipe / FIFO fornita dal sistema operativo.
Sì, starai bene / sicuro. Dal primo link su Tubi e amp; FIFO che hai fornito nei commenti:
POSIX.1-2001 says that write(2)s of less than PIPE_BUF bytes must be atomic:
E dai limits.h che hai collegato:
13 #define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
Dato che stai scrivendo < = 300 byte e la dimensione del buffer minimo POSIX per una scrittura atomica è 512 byte, sei molto chiaro. Per essere paranoico, puoi ricontrollare la dimensione PIPE_BUF nei limiti locali.h, ma non è realmente necessario.
Le tue scritture sono garantite thread-safe poiché stai scrivendo meno della dimensione del buffer pipe. Allo stesso modo, le tue letture dovrebbero essere corrette e / o dovrebbero avere il vantaggio del blocco del dispositivo che impedisce l'accesso a due thread contemporaneamente.
Leggi altre domande sui tag c multithreading