The local block has a number of challenges to its specification and use
that have caused us to explore data-centric means of getting the same
benefits without throwing such a big hammer. Ben's prototypical local
class pragma support that went into 1.11 is one example of this; the
notion of getting a "local array slice" that only supports access to local
elements is a second. In my mind, one of the goals we're working toward
(ideally by 1.12, but it may take longer) is to deprecate the local block
altogether. This is part of the reason that (I believe) it's never made
it into the language spec. It's been viewed as more of a stopgap than a
desireable feature for a long time.
I don't have as many thoughts about the serial block, in part because I
don't feel like it sees much use in practice. It could, arguably, make
sense to make it completely local to a given parallel construct or to make
it lexically scoped.
-Brad
On Thu, 4 Jun 2015, Michael Ferguson wrote:
> Hi Chapel Developers -
>
> It came up recently that local { } does not compose well
> with library code. By that, I mean that the library code
> won't necessarily function when it's in a local block. If
> the library code needs to communicate - it will fail if
> it's called from within a the local block, but the error
> message doesn't necessarily lead directly to the problem.
>
> I believe that the same problem also exists for serial
> blocks, but for a different reason. There, the library
> code might need to actually create multiple tasks in
> order for its algorithm to work. When it tries to synchronize
> those tasks, it will probably deadlock if they are not
> actually tasks but instead run serially.
>
> I have some questions about this dilemma.
>
> 1) Is there already a planned strategy for solving this
> problem, possibly by replacing local { } and serial { }
> with something else?
> 2) If we want to keep local { } and serial { } as
> performance optimizations, could we provide a way for
> library code to assert that it needs communication or
> task parallelism? Something like:
>
> proc libraryFnThatCommunicates() {
> assertNotInLocalBlock();
> ...
> }
>
> and
>
> proc libraryFnThatSynchronizesSpawnedTasks() {
> assertNotInSerialBlock();
> ...
> }
>
>
> 3) Another idea would be to only allow local/serial blocks
> to call functions that are marked in some way that
> they are compatible with local/serial blocks...
> but I think I prefer the assert method.
>
> 4) A completely different strategy would be to make
> better stack traces for failed tasks, including
> tracing through 'on' statements.
>
> Interested in your thoughts,
>
> -michael
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Chapel-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
