`tbb::task_arena::enqueue` should at least document that execution order isn't guaranteed about onetbb

[pavelkumbrasev]

Hi @BenFrantzDale, there is no mention of FIFO guarantee into enqueue specification.
arena.max_concurrency() was improved for a case tbb::task_arena{1,0} (in #1128) but tbb::task_arena{1} will still require additional slot for a worker thread because of enqueue logic support thus arena.max_concurrency() == 2.

[BenFrantzDale]

@pavelkumbrasev Thanks. From those docs I'm still not clear what reserved_for_masters means and how max_concurrency and reserved_for_masters interact to produce the int max_concurrency() const result.

I know there's no mention of a FIFO guarantee in enqueue. I'm suggesting that I wished it would affirmatively state that there is no guarantee, especially with a name like "enqueue" versus, say, submit or detach which don't have the same potential FIFO impliciations. In contrast, it does say "Caution: There is no guarantee that tasks enqueued into an arena execute concurrently with respect to any other tasks there." which I read and think: Obviously, there may be only one worker available, and in general, execution order won't be guaranteed because one worker could pick up a task, then immediately go to sleep, then another could pick up the "next" one and do it to completion, giving the effect of the latter one executing first.

I'd be happy to PR documentation changes to clarify, but I'm not sure what the rules actually are.

And in general, if you know a way to set tbb::task_arena or other things up to guarantee FIFO execution (never concurrent), I'm all ears.

[pavelkumbrasev]

Hi @BenFrantzDale,
We add extra slot for worker thread in case of tbb::task_arena{1} to support fire-and-forget logic for enqueue tasks. So such arena will have increased concurrency.

You can submit PR into oneTBB specification. There is a link to a PR as an example.