1

In Boost interprocess, is it possible to use a condition variable with a sharable mutex? I have one writer and multiple readers that need to wait on the writer.

More specifically, using named_condition_any::wait fails because it internally calls unlock() but sharable_lock requires unlock_sharable(). How could I get around this?

LanguagesNamedAfterCofee
  • 5,782
  • 7
  • 45
  • 72
  • Can you explain your use case a little bit? I'm have a very hard time imagining any use case where this would be a good choice. – David Schwartz May 30 '17 at 20:53
  • 1
    Write a toy adapter? – Yakk - Adam Nevraumont May 30 '17 at 21:10
  • @DavidSchwartz I have one writer and multiple readers. The readers don't modify the shared memory, so they can read in parallel (thus needing a sharable mutex). However, they must wait for the writer to populate new data. The condition variable is for waiting on new data to arrive. – LanguagesNamedAfterCofee May 30 '17 at 22:37
  • And the reading takes a significant fraction of the time they spend waiting? If not, why use a shared mutex since it's just released while they're waiting anyway? And the readers need to run each time there's an update but it's okay if they miss an update? – David Schwartz May 30 '17 at 23:29
  • @DavidSchwartz The point of the shared mutex is so that the readers can read concurrently, and it's not ideal if they miss an update. In my scenario, it probably is a premature optimization (since I only have three readers that spend most of the time waiting). However, for future reference, it seems like good design to have concurrent readers. – LanguagesNamedAfterCofee May 30 '17 at 23:40
  • @LanguagesNamedAfterCofee But it's not a good design to have concurrent readers unless they spend a significant amount of time reading. It's much more complex to acquire and release a shared lock than an unshared one. And if the threads spend so little time there's almost no contention, that additional cost is never paid back. Use of a shared lock makes wait morphing impossible, negating much of the benefit of using a condition variable on modern systems. – David Schwartz May 30 '17 at 23:42
  • @DavidSchwartz By complex do you mean in terms of overhead compared to a normal lock? Also, a scenario I'm imagining is thousands of readers that while taking little time to read individually, add up to quite a bit of time. Having them be able to read concurrently would speed up the time. – LanguagesNamedAfterCofee May 30 '17 at 23:46
  • @LanguagesNamedAfterCofee Yes, overhead compared to a normal lock. It's possible that you're right about it being a speedup, but it's extremely unlikely. And if you have thousands of threads, you clearly don't care one bit about performance anyway. – David Schwartz May 30 '17 at 23:48
  • @DavidSchwartz Interesting, I didn't realize there would be extra overhead compared to a normal lock. Good to know. Also, I mean thousands of processes, not threads, but I admit that this scenario is getting more and more contrived. – LanguagesNamedAfterCofee May 30 '17 at 23:51

0 Answers0