2 Q's , Threads and Deallocate, Allocate and Heap

[SamL]

Can this be expanded on by any of the experts here.

Questions 1
From the Manual, Deallocate
"Deallocate is an alias for the C runtime library's free, so it's not guaranteed to be thread safe in all platforms."

Does this mean if the code is in a multi thread environment will simply using MutexLock / MutexUnLock around all Deallocate calls make it thread safe or will other things cause issues such as when other threads are calling subs/functions that use dim?

What is the way to make Deallocate thread safe, or is this not possible?
what platform(s) are threadsafe with Deallocate ?

Questions 2
One more question,
From the Manual, Allocate
"Attempts to allocate, or reserve, count number of bytes from the free store (heap). The newly allocated memory is not initialized."

Is the free store the memory of the thread ( memory size set at threadcreate ) that uses Allocate or will it use memory of the main thread ( the memory size that is set at compile time )

Is callocate / allocate thread safe?

Thanks for the help!!

Regards,
SamL

[fxm]

Originally, Allocate, CAllocate, ReAllocate and DeAllocate were not thread-safe! You needed [MutexLock ... MutexUnlock] blocks in all threads around these procedures.
Now, I don't know!

In any case, the memory is allocate in the heap, never in the specific stack of each thread.

[fxm]

I found a post from dkl (Site Admin / 12 Mar 2012):

I don't think there's a reason to worry about thread-safety of Allocate() (also known as malloc()) and related functions.....
The malloc implementation of glibc on GNU/Linux and msvcrt on Windows are definitely thread-safe. There can be such problems if you're using other CRTs, but that won't happen unless you're hacking FB or linking manually. The FB rtlib itself uses malloc() & co extensively, for example for dynamic strings, and that's not always synchronized, plus even if the FB rtlib would lock a mutex, anyone else using malloc() would have to lock the same mutex to make it safe, but that's definitely not happening either. So essentially the FB runtime itself would need to be fixed to work-around a thread-unsafe malloc(). So yeah, that's why I say don't worry about it, and happy coding!

So I think we could remove all such warnings in the documentation.

[SamL]

ok it looks like the warning "This function is not part of the FreeBASIC runtime library, it is an alias for the C runtime library's realloc, so it's not guaranteed to be thread safe in all platforms." is only for Reallocate and Deallocate.

so it looks like those two commands need mutexe still at least.

Now i need to learn more about the heap because i need to allocate larger chunks of memory.

Thanks!

Regards, SamL

[fxm]

I don't think there's a reason to worry about thread-safety of Allocate() (also known as malloc()) and related functions.....

So I think we could remove all such warnings in the documentation.

And this for all the keywords: Allocate, CAllocate, ReAllocate and DeAllocate.


[edit]
Done:
- KeyPgReallocate → fxm [unless proven otherwise, this procedure is thread-safe]
- KeyPgDeallocate → fxm [unless proven otherwise, this procedure is thread-safe]
- KeyPgCallocate → fxm [unless proven otherwise, this procedure is thread-safe]
- KeyPgAllocate → fxm [unless proven otherwise, this procedure is thread-safe]