L'IPC Boost è buono?

Question

La mia scelta predefinita per IPC multipiattaforma sarebbe stata positiva, ma l'ho vista criticata in due forum diversi quando gli ho chiesto spiegazioni e questo mi preoccupava. Forse questa era semplicemente una coincidenza, quindi quali sono le considerazioni su boost IPC e sulla scelta di una libreria IPC C++ multipiattaforma in generale?

Per Windows dev, stiamo usando VC++ 2008 come riferimento.

edit: ecco un esempio di commenti che ho visto fatto (non può trovarli tutti in questo momento):

per spinta, fa schifo. Almeno nelle finestre . I Mutex non utilizzano WinAPI, , ma creano la propria implementazione basata su file (WinAPI = Oggetti kernel). Se il tuo programma si arresta in modo anomalo, i file non verranno cancellati. La prossima volta che viene lanciato il programma non è possibile creare il mutex, a causa di il file esistente.

Answer 1

Dalla mia esperienza limitata con Boost.Interprocess, non ho avuto grossi problemi, ma non posso davvero commentare le prestazioni. Anche se è vero che usa i file creati al di fuori della cartella del tuo programma per fare le sue cose, dovrebbero essere tutti mappati in memoria che annullano la maggior parte dei problemi di prestazioni. In ogni caso, quando utilizzi IPC dovresti sempre aspettarti un extra di prestazioni extra.

Per quanto riguarda le critiche evidenziate, è possibile rimuovere un mutex denominato o qualsiasi altra risorsa denominata che è stata lasciata in giro da un processo precedente (vedere la funzione statica remove(const char*)). Per essere onesti, a seconda della tua applicazione, potrebbe essere difficile da usare correttamente che non è qualcosa che devi affrontare quando usi l'API di Windows. D'altra parte, l'API di Windows non è portabile. La mia ipotesi è che usano i file (anche quando esiste un'alternativa migliore) per mantenere l'interfaccia e il comportamento della libreria coerenti su piattaforme diverse.

In ogni caso, i mutex denominati sono solo una piccola parte di ciò che fornisce la libreria. Una delle caratteristiche più utili è che fornisce il suo own memory managers for the shared memory region che include STL allocators. Personalmente trovo più piacevole lavorare con i costrutti di alto livello che fornisce poi con la memoria grezza.

---

UPDATE: ho ancora un po 'scavare la nella documentazione Boost e mi sono imbattuto in diversi interessanti tid bit:

This page dà un po' più particolare circa l'attuazione e le prestazioni della biblioteca, ma non include una logica di implementazione.

This link indica chiaramente che l'implementazione di mutex di Windows potrebbe utilizzare un po 'di lavoro (versione 1.46). Se si scava un po 'di più nella cartella boost\interprocess\sync, si noteranno altre due cartelle denominate posix e emulation. Entrambi contengono i dettagli di implementazione per la primitiva di sincronizzazione.L'implementazione POSIX per interprocess_mutex::lock è quello che ci si aspetterebbe, ma l'attuazione di emulazione è piuttosto semplice:

// Taken from Boost 1.40. 
inline void interprocess_mutex::lock(void) 
{ 
    do{ 
     boost::uint32_t prev_s = detail::atomic_cas32(const_cast<boost::uint32_t*>(&m_s), 1, 0); 

     if (m_s == 1 && prev_s == 0){ 
      break; 
     } 
     // relinquish current timeslice 
     detail::thread_yield(); 
    }while (true); 
} 

Così, gli sguardi di esso, si rivolge per il supporto Posix e blobbed tutto il resto in uno strato di emulazione, che utilizza la memoria mappata File. Se vuoi sapere perché non forniscono un'implementazione specializzata di Windows, ti suggerisco di chiedere la mailing list di Boost (non ho trovato nulla nel documento).

Answer 2

Questa non è una risposta diretta alla domanda, ma un'alternativa: se si dispone di una scelta sull'ambiente di sviluppo, è possibile considerare Qt e the D-bus implementation in Qt.