On 12 Jun 2022, at 18:40, Gonzalo Garramuno wrote:
>
>
>> El 12 jun. 2022, a las 14:29, Ian MacArthur <imacarthur@gmail.com> escribió:
>>
>> Now, it is entirely possible that the modern OS memory allocators are fully multi-thread aware and so do not cause a serialization when used like this, but I am old now and do not know!
>>
>
> The new and delete operators are thread safe.  Malloc is safe depending on OS and compiler flags.  On modern Unix, it is thread safe.  On Windows, it is thread safe if compiled with one of the multithreaded flags (like /MD).
> Or at least that’s what stack overflow said :D

Sorry, I was not clear: I have no doubt they are thread-safe, rather what I do not know is how that safety is achieved.
Historically it was achieved by having a "global lock" on the heap, which had the effect that if multiple threads were allocating/deallocating they would be serialized at that point, breaking the multi-thread nature of the operations.

Now, there are lockless ways this can be done, and it is entirely feasible that the modern allocators do that (I think that is what Matt is saying) but certainly in the past the allocators were rendered thread-safe by dint of using what was essentially a master lock, and I have seen this have “unfortunate” side effects that badly perturbed the multi-thread nature of the runtime code.
So I try to avoid that (which is why I, I suppose, I don’t know whether it is even true or not now!)






--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/F1C78245-B245-4CF6-9E04-6D0C8D9222C0%40gmail.com.