Quick questions about parallelism and some amber features
David Alayachew
davidalayachew at gmail.com
Sun Apr 23 19:04:29 UTC 2023
Hello Holo,
Thank you for your response!
> I don’t see how you can have parallelism without having
> some horrible potential bugs.
> Imagine the following situation:
>
> public static AtomicBoolean bl = new AtomicBoolean(true);
> public static void sideEffect() {
> bl.set(false);
> return true;
> }
> ...
> Integer i = 0;
> switch (i) {
> case Integer i when bl.get() -> ...
> case Integer i when sideEffect() -> ...
> ...
> }
>
> In this example we can have:
>
> - Enter case 1 with correct state
> - Enter case 2 with correct state
> - Enter case 1 with wrong state
>
> Using move variables we can create a (albeit a bit
> pathological) example with any number of cases that all
> can be entered with a wrong state (apart from maybe the
> default branch).
Yes, no matter what, side effects can cause all of this to fall apart.
Though, I would say that that already sounds like a pretty severe code
smell, if not a bug (with the exception of maybe execution counters or
something like that). And that's excluding parallelism here, just plain
sequential execution of the cases.
> Also, it can be dangerous when the when clause is
> expensive. Maybe it is possible to calculate the non-when
> clause in parallel fashion, but I don’t know if it worth
> the effort
I see what you mean. An extremely expensive when clause that should be
called only when all other cases fail would cause pretty severe performance
problems for no good reason. And realistically, the same could be said of
the deconstruction pattern too. Now that user created deconstruction
patterns are coming down the pipe, that technically means that
deconstruction could be expensive too.
Furthermore, reading your comment just now made me think of a problematic
example.
final int someInt = 20;
final String response =
switch (someInt)
{
case Integer i when i >= 0 && i < 10 -> "a";
case Integer i when i >= 10 && i <=20 -> "b";
case Integer i when i >= 20 && i < 30 -> "c";
case null, default ->
throw new IllegalArgumentException("?!");
};
Sequential execution will always return "b", but parallel execution might
return "c", assuming no clean up effort by Java to return the "top-most
case".
In short, you raised a pretty definitive point in why concurrent execution
would be problematic. And Steve mentioned earlier in this thread that the
overhead would be too much, so I definitely see what you mean.
And to be clear, my OP and subsequent responses are all purely with
knowledge gathering intent. I want to learn more about how parallelism is
used in Java. This is certainly no feature request or "feasability request".
Thank you for your insight!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230423/872d0744/attachment.htm>
More information about the amber-dev
mailing list