On 21 October 2011 15:31, Torvald Riegel wrote: > Hello everyone, > > we thought to take this conversation to the list because it is related > to the GCC implementation of Cilk+. My questions to Balaji are quoted, > Balaji's replies are marked with BVI>. > > On Fri, 2011-09-23 at 10:42 -0700, Iyer, Balaji V wrote: >> > 1) Implicit syncs are said to be called after destructors. However, >> > this seems to be counter-intuitive for programmers. What was the >> > reasoning to choose that instead of running destructors after the >> > implicit sync? Was it about performance? >> > >> > >> > BVI) Implicit syncs: It is true that in most cases it would be better >> > to sync before calling destructors in order to avoid race conditions. >> > However, destructors are often used to release locks. >> >> Agreed, but I would assume that this is not that common. Are there any >> common cases _besides_ lock objects for block scope? OTOH, I can't think >> of any other objects that would hold locks throughout their whole >> lifetime instead of just during individual operations. Do you have >> any examples of other common objects/patterns?
It's not a lock, but an unsatisfied std::promise makes its shared state ready in its destructor (setting std::future_errc::broken_promise), which would unblock any threads waiting on a future with the same shared state. >> BVI> We don't have any other examples off hand, but the lock-guard case is a >> BVI> very common one and is especially important now that it is part of the >> BVI> new C++ standard. > > Hmm. Could we make a special case for lock guards? That is, have them be > called before the sync, so that we first call all lock-guard > destructors, then the sync, then the rest of the destructors? Then we'd > still release locks released from other destructors after the case. What about user-defined lock guards? The C++ Lockable requirements don't just apply to std::lock_guard and std::scoped_lock. Can you correctly determine whether something is a lock guard? > However, this changes the desctructor order, Surely that's not an option then.
