This is the mail archive of the
mailing list for the GCC project.
Re: Cilk+ questions
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>, Jeff Law <law at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 21 Oct 2011 16:37:58 +0100
- Subject: Re: Cilk+ questions
- References: <email@example.com> <2950715866004049A240A2F9BB410E7315F220450B@azsmsx502.amr.corp.intel.com> <firstname.lastname@example.org> <2950715866004049A240A2F9BB410E7315F3F030FA@azsmsx502.amr.corp.intel.com> <email@example.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.