ManagedBlocker.block() documentation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ManagedBlocker.block() documentation

JSR166 Concurrency mailing list
Currently, ManagedBlocker's documentation doesn't clarify whether the execution framework could call block() more than once or not. The specification for the return value of block() method:

> true if no additional blocking is necessary (i.e., if isReleasable would return true)

Implies that isReleasable result should change if block() returns true.

It means that to code one-off blocking ops with ManagedBlocker, strictly against the spec, one must make block() idempotent:

class MyBlocker implements ManagedBlocker {
  boolean done = false;
  boolean block() {
    if (done) return true;
    doMyOneOffBlockingOp();
    done = true;
    return true;
  }
  boolean isReleasable() { return done; }
}

Which is 1) boilerplate 2) non-trivial conclusion, implicit in the doc (so few people would probably do this; e. g. there is an SO answer from a very reputable folk that ditch this complexity and call it an "official solution": https://stackoverflow.com/a/46073118/648955)

So, perhaps, it would make sense to extend the documentation of ManagedBlocker with reservations about one-off blocking operations, e. g. like this:

@return true if no additional blocking is necessary (i.e., if isReleasable would return true, or if block() is a one-off operation)

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ManagedBlocker.block() documentation

JSR166 Concurrency mailing list
I typically do this:

class MyBlocker implements ManagedBlocker {
  boolean done;
  boolean block() {
    if (!isReleasable()) {
      doMyOneOffBlockingOp();
      done = true;
    }
    return isReleasable();
  }
  boolean isReleasable() { return done; }
}

In Scala I added a `blocking` construct which takes a thunk so the users can write:

val result = blocking { doMyOneOffBlockingOp() }

On Wed, Oct 30, 2019 at 7:26 AM Roman Leventov via Concurrency-interest <[hidden email]> wrote:
Currently, ManagedBlocker's documentation doesn't clarify whether the execution framework could call block() more than once or not. The specification for the return value of block() method:

> true if no additional blocking is necessary (i.e., if isReleasable would return true)

Implies that isReleasable result should change if block() returns true.

It means that to code one-off blocking ops with ManagedBlocker, strictly against the spec, one must make block() idempotent:

class MyBlocker implements ManagedBlocker {
  boolean done = false;
  boolean block() {
    if (done) return true;
    doMyOneOffBlockingOp();
    done = true;
    return true;
  }
  boolean isReleasable() { return done; }
}

Which is 1) boilerplate 2) non-trivial conclusion, implicit in the doc (so few people would probably do this; e. g. there is an SO answer from a very reputable folk that ditch this complexity and call it an "official solution": https://stackoverflow.com/a/46073118/648955)

So, perhaps, it would make sense to extend the documentation of ManagedBlocker with reservations about one-off blocking operations, e. g. like this:

@return true if no additional blocking is necessary (i.e., if isReleasable would return true, or if block() is a one-off operation)
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ManagedBlocker.block() documentation

JSR166 Concurrency mailing list
Maybe is should actually be put in code. Something like
public interface ManagedBlocker {

// Note: Runnable is not a good choice, the method show allow to throw an InterruptedException
static ManagedBlocker blocker(Runnable blockingOperation) {
return new ManagedBlocker() { // Probably better to have a real class, not an anonymous one
private volatile boolean done; // Is volatile needed?

public boolean block() throws InterruptedException {
if (!isReleasable()) {
blockingOperation.run();
done = true;
}
return isReleasable();
}

public boolean isReleasable() {
return done;
}
};
}
boolean block() throws InterruptedException;
boolean isReleasable();
}

On Wed, 30 Oct 2019 at 04:00, Viktor Klang via Concurrency-interest <[hidden email]> wrote:
I typically do this:

class MyBlocker implements ManagedBlocker {
  boolean done;
  boolean block() {
    if (!isReleasable()) {
      doMyOneOffBlockingOp();
      done = true;
    }
    return isReleasable();
  }
  boolean isReleasable() { return done; }
}

In Scala I added a `blocking` construct which takes a thunk so the users can write:

val result = blocking { doMyOneOffBlockingOp() }

On Wed, Oct 30, 2019 at 7:26 AM Roman Leventov via Concurrency-interest <[hidden email]> wrote:
Currently, ManagedBlocker's documentation doesn't clarify whether the execution framework could call block() more than once or not. The specification for the return value of block() method:

> true if no additional blocking is necessary (i.e., if isReleasable would return true)

Implies that isReleasable result should change if block() returns true.

It means that to code one-off blocking ops with ManagedBlocker, strictly against the spec, one must make block() idempotent:

class MyBlocker implements ManagedBlocker {
  boolean done = false;
  boolean block() {
    if (done) return true;
    doMyOneOffBlockingOp();
    done = true;
    return true;
  }
  boolean isReleasable() { return done; }
}

Which is 1) boilerplate 2) non-trivial conclusion, implicit in the doc (so few people would probably do this; e. g. there is an SO answer from a very reputable folk that ditch this complexity and call it an "official solution": https://stackoverflow.com/a/46073118/648955)

So, perhaps, it would make sense to extend the documentation of ManagedBlocker with reservations about one-off blocking operations, e. g. like this:

@return true if no additional blocking is necessary (i.e., if isReleasable would return true, or if block() is a one-off operation)
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


--
Cheers,
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ManagedBlocker.block() documentation

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
On 10/30/19 3:23 AM, Roman Leventov via Concurrency-interest wrote:
> Currently, ManagedBlocker's documentation doesn't clarify whether the
> execution framework could call block() more than once or not. The
> specification for the return value of block() method:

This seems implicit in the interface-level description, but we'll add a
clarification:

     * Method {@code block} is not invoked after a prior invocation of
     * {@code isReleasable} or {@code block} return {@code true}.
     *

-Doug

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ManagedBlocker.block() documentation

JSR166 Concurrency mailing list
"return" -> "returns" ?

On Wed, Oct 30, 2019, 9:50 AM Doug Lea via Concurrency-interest <[hidden email]> wrote:
On 10/30/19 3:23 AM, Roman Leventov via Concurrency-interest wrote:
> Currently, ManagedBlocker's documentation doesn't clarify whether the
> execution framework could call block() more than once or not. The
> specification for the return value of block() method:

This seems implicit in the interface-level description, but we'll add a
clarification:

     * Method {@code block} is not invoked after a prior invocation of
     * {@code isReleasable} or {@code block} return {@code true}.
     *

-Doug

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ManagedBlocker.block() documentation

JSR166 Concurrency mailing list
On 10/30/19 9:58 AM, Tim Peierls via Concurrency-interest wrote:
> "return" -> "returns" ?

Right; thanks. Plus we can further simplify as:

     * Neither method is invoked after a prior invocation
     * of {@code isReleasable} or {@code block} returns {@code true}.

>
> On Wed, Oct 30, 2019, 9:50 AM Doug Lea via Concurrency-interest
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 10/30/19 3:23 AM, Roman Leventov via Concurrency-interest wrote:
>     > Currently, ManagedBlocker's documentation doesn't clarify whether the
>     > execution framework could call block() more than once or not. The
>     > specification for the return value of block() method:
>
>     This seems implicit in the interface-level description, but we'll add a
>     clarification:
>
>          * Method {@code block} is not invoked after a prior invocation of
>          * {@code isReleasable} or {@code block} return {@code true}.
>          *
>
>     -Doug
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest