Ion Gaztañaga <igaztanaga@gmail.com> writes:
Anthony Williams wrote:
Ion Gaztañaga <igaztanaga@gmail.com> writes:
Hi to all,
Recently some bug reports were issued against Boost.Interprocess' condition variable. Since my multithreading skills are limited at best, I was wondering if Boost.Thread developers/threading experts would like to help on rewriting the condition variable.
Sure, I'll help. Are you after a general rewrite, or just a fix for ticket 1231?
Whatever you consider more appropriate. I pretty sure that instead of just doing yields, you could come up with a more efficient approach ;-) Now seriously, I think a complete rewrite by a threading expert would be more appropriate if the effort is assumable.
I'll see what I can come up with. If there are no native process-shared sync objects, I'd be hard-pushed to think of anything better than yielding.
On Windows, I'd have thought we could use process-shared sync objects, but that doesn't solve the general emulation problem.
Does this support building those objects in mapped files, rebooting the system, mapping the file again again and continue working?
Sort-of. Named mutexes (for example) can be shared across processes --- every process that tries to create a mutex with a specified name gets the same mutex. If you store the name in a file then you'll get the same mutex back when you read back the file (though it will always be unlocked after a reboot). If use a UUID as the name, then you know it won't clash with anything else. What are the requirements with respect to memory mapped files? Does the locked state (and thus owner) of the mutex need to be sticky? How does this work with a process-shared pthread_mutex_t? Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL