This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gomp4] Compiler side of the cancellation support

On 07/03/2013 03:39 AM, Jakub Jelinek wrote:
> Hi!
> This is the compiler side of the #pragma omp cancel and #pragma omp
> cancellation point support.  On the library side what is needed is:
> 1) GOMP_cancellation_point now returns a bool (whether the relevant
>    cancellation was observed)
> 2) GOMP_cancel now has two arguments instead of just one, and returns
>    bool like GOMP_cancellation_point.  If the second argument is false,
>    it acts just like GOMP_cancellation_point, if it is true, it cancels
>    the given construct.  For both these calls the first argument is
>    1 for parallel cancellation, 2 for loop cancellation, 4 for sections and
>    8 for taskgroup cancellation.
> 3) GOMP_barrier_cancel which is like GOMP_barrier, but should check
>    for pending parallel cancellation and if parallel is cancelled, should
>    return true
> 4) GOMP_sections_end_cancel and GOMP_loop_end_cancel variants to the
>    non-cancel libcalls for the cancellation checking implicit barriers
> The still unsolved problems are that for firstprivate/lastprivate
> for, copyin_ref we add an implicit barrier that isn't really in the standard
> and similarly for #pragma omp single copyprivate we don't use one barrier
> mandated by the standard, but actually two barriers.  Not sure what exactly
> we want as the behavior for these.  As some subset of threads can be
> canceled before reaching the unofficial barrier (say one with #pragma omp
> cancel parallel before reaching the omp for or omp single copyprivate)
> and some others with #pragma omp cancellation point parallel, while some
> threads hit the unofficial barrier before the cancellation (and optionally
> some afterwards), do we want in the library to just arrange for all barriers
> to be awaken and not block until the final barrier at the end of parallel is
> hit, and for the unofficial barriers just not to return anything, while
> for the official barriers (*_cancel suffixed) return true to signal jump to
> end of region with running dtors?
> Or perhaps keep track on how many threads in parallel have already observed
> the cancellation and wait on non-*_cancel barriers only for the rest of the
> threads that haven't observed it yet, and only on the *_cancel barriers
> observe it for all threads.
> Another issue is what if the dtors executed on the way contain barriers,
> but that is probably ruled out by the restriction that 
> "A construct that may be subject to cancellation must not encounter an orphaned
> cancellation point."
> Queuing this patch until we have a library implementation.

I've committed the patch, so that I can more easily work on the library
implementation.  There was one minor patch conflict that needed resolving.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]