Clarify docs and improve pool API thread-safety guarantees if possible

[tomilov]

I suspect working with pool for specific pool can be thread-safe (even with VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT set but without actual synchronization) relative to working with other pools and general API. E.g. I allocate pool with maxBlockCount == minBlockCount for each specific worker thread and use it in conjunction with dedicated (per thread) VkQueue. Can it be "isolated" from other stuff if I do not use any "global" API functions (like statistics)? Is it currently true or is it close to true and only requires minor changes in vk_mem_alloc.h code?

[adam-sawicki-a]

I am sorry, but with VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT flag, using VMA functions is not thread-safe, and using separate custom pools is not exception. Pools are not completely separate. They need to synchronize, for example, to update global statistics about the number of memory blocks, allocations, or bytes used.

Is the performance overhead of thread synchronization really a problem for you that you measured? I doubt it could be a problem considering that GPU memory allocations are heavy operations that should not be performed too often.

[tomilov]

This is not a problem in particular case, but what I talking about is a possible improvement: I think global statistics on separate pool can be sacrificed in favor of thread individual thread safety of using separate memory pool.
I always can make multiple allocators with unique thread affinity, but overhead may be much greater then in hypotetical case, when thread safety guaranteed by library for separate pools.