Re: Cilk+ questions

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

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.