Task Runner and memory order

[Hong Xu]

@Leonid Baraz and I have a question regarding whether an explicit memory barrier is needed when variables are passed to another posted task.

Here's a minimal example.

```

class C {
public:
  bool v = false;
};

PostTaskBasedOnV() {
  auto c = std::make_unique<C>();

  c->v = true;
  base::ThreadPool::PostTask(
  FROM_HERE,
  base::BindOnce([](std::unique_ptr<C> c) {
    if (c->v) {
      // Do something...
    }
  }, std::move(c)));
}

```

- When PostTaskBasedOnV is called for the first time, would c->v be potentially affected by memory reordering, i.e., c->v is false when the post task is being executed? In other words, does the ThreadPool establish some kind of hidden memory barriers?

- What if ThreadPool::PostTask is replaced by SequencedTaskRunner::PostTask?

Thank you,

Hong

[Etienne Pierre-doray]

Hi Hong,

PostTask does imply an implicit memory ordering (posting happens-before running the task, equivalent to release-acquire synchronization), much like starting a thread or taking a lock. This is the case for both ThreadPool and SequencedTaskRunner.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAH6dBrHUa2JWNw9bBpXmTZq3AH-FmHN53mTz-07gynomd3Wvdw%40mail.gmail.com.

[Hong Xu]

Thank you so much, Etienne!

[Hong Xu]

Do you know if this is formally documented somewhere?

On Mon, Jan 16, 2023 at 8:21 AM Etienne Pierre-doray <etie...@chromium.org> wrote:

[Gabriel Charette]

Not really, but it's implicit in the definition of "happens-after" (key to studying parallel systems). It's impossible for a task not to run "after" it was posted (in this case, the queue has a lock so this is clear, but even a lock-free queue would have to provide this guarantee or everything would explode).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAH6dBrFv%3DN4a_u9NihOvCLiNmoJ%2Bj1ZiYBms1cp9k%3DAREOpS%2BA%40mail.gmail.com.

[Egor Pasko]

Anecdotal evidence: I often hear this question from people new to the chromium codebase.

There are several ways to post a task, and the concurrency guarantees of doing so are not easily readable from all the variants in the code. Therefore it would be nice to clarify this in documentation. Would it be correct/enough to say that PostTask and the execution of the posted task are in the happens-before relationship with each other for all the ways to post a task?

2c: I'm suggesting happens-before over happens-after on purpose: the latter is only very rarely used in standards, APIs, CS articles and other literature.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAJTZ7LJ2yvaxF%2BFebgjn9xHnr_R%2BnTk1sSXyDS8di%3Dhj3cFHUw%40mail.gmail.com.

[Gabriel Charette]

My worry with adding the doc to some PostTask's is that it may then yield the implicit question of whether the undocumented ones lack this property (while none can). I'm surprised that there's confusion though as I don't see how a task system could work without this guarantee.

Maybe we can document this globally in threading_and_tasks.md?

Le mer. 15 févr. 2023, 15 h 18, Egor Pasko <pa...@chromium.org> a écrit :

Anecdotal evidence: I often hear this question from people new to the chromium codebase.

There are several ways to post a task, and the concurrency guarantees of doing so are not easily readable from all the variants in the code. Therefore it would be nice to clarify this in documentation. Would it be correct/enough to say that PostTask and the execution of the posted task are in the happens-before relationship with each other for all the ways to post a task?

2c: I'm suggesting happens-before over happens-after on purpose: the latter is only very rarely used in standards, APIs, CS articles and other literature.

Good point, thanks. I often mix the two as equivalent but agreed that nomenclature should use what the spec uses.

[Egor Pasko]

On Wed, Feb 15, 2023 at 10:15 PM Gabriel Charette <g...@chromium.org> wrote:

My worry with adding the doc to some PostTask's is that it may then yield the implicit question of whether the undocumented ones lack this property (while none can). I'm surprised that there's confusion though as I don't see how a task system could work without this guarantee.

Indeed it is hard to imagine a task posting system for Chrome without the guarantee. Though there still is a source for confusion because devs want to know exactly what their primitives do before relying on them. We should respect this willingness to build robust software stack on all levels and document subtle concurrency guarantees in common APIs such as this one, even if those facts can be inferred. There is still a lot to know about Chrome specifics to avoid the confusion: the memory hierarchies we support, the task granularity, the latency guarantees, etc. For someone who is only starting their journey in the codebase, this knowledge is not necessarily a given.

Maybe we can document this globally in threading_and_tasks.md?

Thanks! This looks like a good place to me. Here is my first draft for review: https://chromium-review.googlesource.com/c/chromium/src/+/4261928

[Egor Pasko]

On Thu, Feb 16, 2023 at 7:00 PM Egor Pasko <pa...@chromium.org> wrote:

On Wed, Feb 15, 2023 at 10:15 PM Gabriel Charette <g...@chromium.org> wrote:

My worry with adding the doc to some PostTask's is that it may then yield the implicit question of whether the undocumented ones lack this property (while none can). I'm surprised that there's confusion though as I don't see how a task system could work without this guarantee.

Indeed it is hard to imagine a task posting system for Chrome without the guarantee. Though there still is a source for confusion because devs want to know exactly what their primitives do before relying on them. We should respect this willingness to build robust software stack on all levels and document subtle concurrency guarantees in common APIs such as this one, even if those facts can be inferred. There is still a lot to know about Chrome specifics to avoid the confusion: the memory hierarchies we support, the task granularity, the latency guarantees, etc. For someone who is only starting their journey in the codebase, this knowledge is not necessarily a given.

Maybe we can document this globally in threading_and_tasks.md?

Thanks! This looks like a good place to me. Here is my first draft for review: https://chromium-review.googlesource.com/c/chromium/src/+/4261928

Landed: https://chromium.googlesource.com/chromium/src/+/main/docs/threading_and_tasks.md#Memory-ordering-guarantees-for-posted-Tasks

[Gabriel Charette]

Thanks Egor, asked around and folks thought this was a good idea. With a sharper mind this morning and based on their feedback, I made additional suggestions on the CL which I think would make a nice follow-up.