Re: Thread safety

[Dair G. <da...@re...>]

Edward K. Chew wrote:

>but would you really want to lock every last Submit call or accessor
>function

Yep, if you want to be thread safe then any shared data must be
protected by a lock. Million to one chances (two people writing to the
same variable at the same time) happen all the time as soon as threads
are involved... :-)

The only functions which can avoid locks are those which don't access
shared state, i.e., the only data they manipulate is referenced by their
parameters.

E.g., a C library could easily provide a toupper() that didn't need a
lock, since all the state it needs is on the thread's own stack and
registers.

But something like malloc() will always need a lock, since two threads
could easily call malloc at the same time.


>My allocmem method was simply calling malloc under CodeWarrior, which=20
>was in turn calling NewPtr through a low-level function called=20
>__sys_alloc.  After setting the _MSL_THREADSAFE flag so it would call=20
>MPAllocateAligned instead, I have never experienced another=20
>crash...well, not in THAT part of the code, anyway.  :-)  But if you=20
>have read that NewPtr is safe, let me know and I will submit a bug=20
>report.

If you were calling the MSL malloc from a thread without rebuilding MSL
with _MSL_THREADSAFE, that's the behaviour I would expect (i.e., a
crash).

MSL implements its own memory manager on top of the system API, and so
if you've got multiple threads that memory manager needs to protect its
own data structures.

If you search for __begin_critical_region/__end_critical_region in MSL
you'll see where it applies the lock: these do nothing in default
builds, and acquire a mutex (either pthread or MP API) in thread-safe
builds.


There are several of them, applied in different places: one for memory
management APIs, one for file management APIs, etc.

They could have had one giant MSL lock to protect everything, but
multiple locks gives them better concurrency (but is more complex to
keep straight) since it allows one thread to be inside MSL's fopen while
another is inside malloc.


They use MPAllocateAligned as their underlying allocator because NewPtr
is only thread safe on X - since you could build MSL as thread-safe and
use it with MP tasks on 9, for the _MSL_THREADSAFE builds they need a
low-level allocator that is thread-safe on both platforms.

So I think the reason you're not crashing is not that you're going
through MPAllocateAligned, but that critical_regions.macos.h is
providing real locks rather than no-ops to protect the internals of MSL.

The end result is the same (no crash), but NewPtr is innocent here. ;-)


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/