[PATCH] D142318: [Support] Add PerThreadBumpPtrAllocator class.

[Alexey Lapshin via Phabricator via llvm-commits]

avl added a comment.

In D142318#4269216 <https://reviews.llvm.org/D142318#4269216>, @dexonsmith wrote:

> In D142318#4269161 <https://reviews.llvm.org/D142318#4269161>, @dexonsmith wrote:
>
>> In D142318#4269070 <https://reviews.llvm.org/D142318#4269070>, @dexonsmith wrote:
>>
>>> Seems like threads are assigned IDs from 1 in the ThreadPoolExecutor constructor via calls to work(). The main thread assigns `threadIndex` to 0 in the same place:
>>
>> Aha, looks like I misread the code. The `work()` calls are coming from within a lambda that's executed by the first created thread. So, right now, the main thread has the same threadIndex as the first spawned thread.
>>
>> (But if that's the case, doesn't that cause a problem for the allocator? Doesn't the allocator require that the main thread has a different ID from the worker threads?)
>
> Specifically, if the main thread is doing work concurrently with Thread0, and won't they be using the same slice of the PerThreadAllocator?

My understanding is that it should not be so that the main thread is concurrently doing work with Thread0. If that is the case then the problem exists even without PerThreadAllocator. There was recently fixed a bug when exactly main thread doing work concurrently with Thread0 - D142317 <https://reviews.llvm.org/D142317>

Thus current assumption is that the main thread never works concurrently with Thread0. Because they never work concurrently it is OK to have slice 0 for both : main thread and Thread0.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142318/new/

https://reviews.llvm.org/D142318