🚀 go-pugleaf

Karsten

One answer would be to make your own set of global 'new' operators which
call MPAllocateAligned. Have a look at DebugNew.cp to see how this is done.

Graham

In article
<karsten.loeffler-7D396D.15575505102000@newsserv.uni-tuebingen.de>,
Karsten Loeffler <karsten.loeffler@uni-tuebingen.de> wrote:

| Are there plans at Metrowerks to make the MSL - especially the 'MSL 
| C++.PPC.Lib' - MP-safe?
| That means, to use MPAllocateAligned(...) in the operator new() methods.

Yes, there are plans to migrate to use of the MPxxx calls.  Note that this
will break compatibility with earlier Mac OS's, so it will first probably
be offered as an option.

However, there is really no need for you to wait.  In the shipping
configuration, new simply forwards to malloc.  And malloc has a single
entry point into the OS in pool_alloc.mac.c:  __sys_alloc and __sys_free. 
You can simply substitute calls to the MPxxx functions and recompile the C
lib.

You should also #define _MWMT 1 in <ansi_prefix.mac.h> and recompile the C
and C++ libs.  This will protect the pooling that malloc does with calls
to MPEnterCriticalRegion, etc.  This will also put a mutex object in
std::string to protect two threads from simultaneously fooling with a
string's refcount.  This may degrade performance.  An alternative
std::string implementation is available without refcounting (and mutexes)
with #define _MSL_NO_REFCOUNT_STRING in <mslconfig> (requires a C++ lib
recompile).

Please note that the C++ lib is designed to be "level 1" thread safe.  That is:

   1.  It is safe to simultaneously call const and non-const
       methods from different threads to distinct objects. 

   2.  It is safe to simultaneously call const methods, and
       methods otherwise guaranteed not to alter the state
       of an object (or invalidate outstanding references and
       iterators of a container) from different threads to
       the same object. 

   3.  It is not safe for different threads to simultaneously
       access the same object when at least one thread calls
       non-const methods, or methods that invalidate outstanding
       references or iterators to the object. The programmer is
       responsible for using thread synchronization primitives
       (e.g. mutex) to avoid such situations. 

-Howard

Thank you both, howard an graham.
I'll give the first try to the recompile-C-lib-method.

But there's a problem: While I found the project 'MSL C.PPC.MTrgt.mcp', 
I haven't found one for Carbon (MSL C.Carbon.Lib). 
Where is it?

And a another question (regarding pool_alloc.mac.c):
Is it legal to free every pointer in __sys_free(...) where 
MPGetAllocatedBlockSize(ptr) returns not NULL ? 
And free the remaining with DisposePtr(ptr)?


thanks in advance,
karsten





In article <hinnant-0510001154380001@ith3-473.twcny.rr.com>, 
hinnant@anti-spam_metrowerks.com (Howard Hinnant) wrote:



> In article
> <karsten.loeffler-7D396D.15575505102000@newsserv.uni-tuebingen.de>,
> Karsten Loeffler <karsten.loeffler@uni-tuebingen.de> wrote:
> 
> | Are there plans at Metrowerks to make the MSL - especially the 'MSL 
> | C++.PPC.Lib' - MP-safe?
> | That means, to use MPAllocateAligned(...) in the operator new() 
> | methods.
> 
> Yes, there are plans to migrate to use of the MPxxx calls.  Note that 
> this
> will break compatibility with earlier Mac OS's, so it will first probably
> be offered as an option.
> 
> However, there is really no need for you to wait.  In the shipping
> configuration, new simply forwards to malloc.  And malloc has a single
> entry point into the OS in pool_alloc.mac.c:  __sys_alloc and __sys_free. 
> You can simply substitute calls to the MPxxx functions and recompile the 
> C
> lib.
> 
> [snip]

In article <karsten.loeffler-E694CB.17013406102000@news.belwue.de>,
Karsten Loeffler <karsten.loeffler@uni-tuebingen.de> wrote:

| Thank you both, howard an graham.
| I'll give the first try to the recompile-C-lib-method.
| 
| But there's a problem: While I found the project 'MSL C.PPC.MTrgt.mcp', 
| I haven't found one for Carbon (MSL C.Carbon.Lib). 
| Where is it?

It is a different target in MSL C.PPC.MTrgt.mcp (assuming Pro 6 here). 
Prior to Pro 6 there is no carbonized (production version) MSL C.  For
C++, the same lib is good for carbon and non-carbon (doesn't depend so
much on the OS).

| And a another question (regarding pool_alloc.mac.c):
| Is it legal to free every pointer in __sys_free(...) where 
| MPGetAllocatedBlockSize(ptr) returns not NULL ? 
| And free the remaining with DisposePtr(ptr)?

There are people here who know a lot more about Mac OS than I do, but I
would tend to match NewPtr with DisposePtr and MPAllocate with
MPDeallocate (I'm sure I've misspelled the MP guys).  Or did I
misunderstand the question?

-Howard

In article <karsten.loeffler-96141C.08284709102000@news.belwue.de>,
Karsten Loeffler <karsten.loeffler@uni-tuebingen.de> wrote:

| I've wondered how it can be detected if memory block representented by a 
| pointer wether it was allocated by NewPtr() or MPAllocate().
| But now a will try to alloctae everything with MPAllocate without any 
| use of NewPtr()

You could rig __sys_alloc/free to detect the difference.  Just allocate
some extra space and put a flag there saying who allocated the memory. 
However be careful that the pointer you return has the proper alignment
properties (currently set to 16 byte alignment for AltiVec compatibility).

-Howard

In article <hinnant-0610001317070001@ith3-43b.twcny.rr.com>, 
hinnant@anti-spam_metrowerks.com (Howard Hinnant) wrote:

> In article <karsten.loeffler-E694CB.17013406102000@news.belwue.de>,
> Karsten Loeffler <karsten.loeffler@uni-tuebingen.de> wrote:
> 
> | But there's a problem: While I found the project 'MSL C.PPC.MTrgt.mcp', 
> | I haven't found one for Carbon (MSL C.Carbon.Lib). 
> | Where is it?
> 
> It is a different target in MSL C.PPC.MTrgt.mcp (assuming Pro 6 here). 
> Prior to Pro 6 there is no carbonized (production version) MSL C.  For
> C++, the same lib is good for carbon and non-carbon (doesn't depend so
> much on the OS).

sorry, I've overlooked that.


> | Is it legal to free every pointer in __sys_free(...) where 
> | MPGetAllocatedBlockSize(ptr) returns not NULL ? 
> | And free the remaining with DisposePtr(ptr)?
> 
> There are people here who know a lot more about Mac OS than I do, but I
> would tend to match NewPtr with DisposePtr and MPAllocate with
> MPDeallocate (I'm sure I've misspelled the MP guys).  Or did I
> misunderstand the question?

I've wondered how it can be detected if memory block representented by a 
pointer wether it was allocated by NewPtr() or MPAllocate().
But now a will try to alloctae everything with MPAllocate without any 
use of NewPtr()

karsten