Per quanto ne so nelle versioni precedenti dell'implementazione Boost boost::mutex per Windows è stata eseguita utilizzando sezioni critiche. Ma nella versione più recente di Boost 1.51 ho scoperto che ora l'implementazione di mutex si basa su eventi.Implementazione Boost Mutex per Windows
Qualcuno sa qual è la ragione dietro questo cambiamento? È stato fatto per motivi di prestazioni? Le sezioni critiche diventano deprecate?
Non è meraviglioso che usando boost abbiamo sempre un approccio migliore senza modifiche? Nella nuova versione di boost, boost::mutex, è implementato come uno spinlock ma con l'aiuto di un evento di Windows per evitare l'attesa e l'evento verrà creato solo se necessario, quindi è molto leggero e ha prestazioni molto elevate e abilita anche boost per utilizzare questo peso leggero mutex per l'attesa temporizzata! Penso che questo sia eccellente
Questo non può essere corretto, un vero spin lock è possibile solo in modalità kernel ... – Benj
@ Benj e chi ha detto che abbiamo bisogno di un vero spinlock qui? Molte parti di 'boost' dipendono dallo spinlock implementato usando le variabili atomiche, per esempio dai un'occhiata all'implementazione di' boost :: shared_ptr' e 'boost :: detail :: spinlock' e scrivi un piccolo programma che confronta le prestazioni di quello spinlock implementazione con il lock più veloce implementato su windows e anche su sistemi * nix e si vede che il risultato è meraviglioso! – BigBoss
Sei quasi corretto, ma in realtà 'boost :: mutex' non usa affatto gli spinlock! Utilizza le op atomiche come ottimizzazione: quando si acquisisce il lock, prima (atomicamente) controlla una variabile che indica se il mutex è attualmente bloccato. Se non è bloccato, può continuare (senza dover considerare l'evento win32), questo è il percorso veloce. Se il controllo dice che il mutex è bloccato, entra in gioco la (più) costosa win32. Ma qui niente spinlock ;-) – Frunsi
Hai guardato i cambiamenti al changelog? – PlasmaHH
Per quanto posso vedere, è stato fatto per semplificare e unificare il design di vari mutex: attualmente 'mutex',' timed_mutex', 'try_mutex' - sono tutti implementati usando' detail :: basic_timed_mutex', che non può usare CS. (In realtà, usare CS non è sempre la scelta migliore, dipende dallo scenario di concorrenza, quindi non vale la pena complicare la progettazione per questo.) –
Ti rendi conto che solo i progettisti di boost possono rispondere pienamente a questo. Il resto di noi può solo speculare ... – Tudor