2009-05-18 22 views

risposta

19

La versione corrente di boost::mutex non utilizza né Win32 CRITICAL_SECTION né Win32 Mutex. Invece, utilizza le operazioni atomiche e un evento Win32 per bloccare le attese.

Versioni precedenti (boost 1.34.1 e precedenti) erano un involucro intorno a CRITICAL_SECTION su Windows.

Per inciso, il mutex stesso non ha ambito. Il tipo boost::mutex::scoped_lock e, nelle versioni recenti, boost::lock_guard<boost::mutex> e boost::unique_lock<boost::mutex> forniscono wrapper RAII per il blocco di un mutex per garantire che non si dimentichi di sbloccarlo.

I boost::lock_guard<> e boost::unique_lock<> modelli funzionano con qualsiasi tipo con lock() e unlock() funzioni membro, in modo da poterli utilizzare con mutex inter-processo se lo si desidera.

+0

Grazie per la risposta. – nhaa123

+0

Probabilmente è quasi/efficiente quanto una sezione critica di Win32? – unixman83

+0

@ unixman83: ne dubito, una sezione critica è veloce perché è solo in-process, non è possibile utilizzarla tra i processi. Non è un oggetto kernel, ma gli eventi Win32 lo sono. Quindi suppongo che questo non sia veloce come un CS. – gbjbaanb

1

CRITICAL_SECTION di Win32 può essere utilizzato solo tra i thread di un singolo processo. Se è necessario utilizzare qualcosa tra i processi, è necessario un mutex. Boost non dice nulla sulle sezioni critiche, quindi suppongo che stia usando i mutex.

"ambito" significa solo che ha un wrapper che utilizza RAII per sbloccare automaticamente il mutex alla fine di un particolare ambito.

+0

Sì, questi lo sapevo già. Hmm, suppongo di dover esaminare la sorgente reale più avanti .. – nhaa123

+0

Se lo chiamano un "mutex", e non menzionare la frase "sezione critica" assumere con probabilità molto alta che non è un fattore critico sezione –

+0

Hah, ben pensato :) – nhaa123

Problemi correlati