Re: OT List utilities & Classic not mixing well (for me)
Re: OT List utilities & Classic not mixing well (for me)
- Subject: Re: OT List utilities & Classic not mixing well (for me)
- From: Quinn <email@hidden>
- Date: Fri, 26 Mar 2004 10:05:03 +0000
At 21:19 -0800 25/3/04, Graham Parkinson-Morgan wrote:
I read in technote 1127
(http://developer.apple.com/technotes/tn/tn1137.html) that the lwarx
instruction has caveats and DTS has proscribed it.
Presuming I am on the right track, what might be the cure?
Indeed, but that advice applies to your code, not to the OS itself.
The use of these instructions in OT is contained within a dynamically
linked library. If the processor you're running on need some special
coddling, we can supply the appropriate dynamically linked library
and your application automatically benefits.
btw That comment is in Technote 2006.
<
http://developer.apple.com/technotes/tn/tn2006.html>
For OS9 & Classic, the project is linked against OpenTptXXXXPPC.o
libraries in CW/MacOS Support/Universal/Libraries/PPC Libraries.
This is also a red herring. While this library is statically linked,
it doesn't contain any real functionality. If you take a look at
Technote 1173 it explains what the non-dynamically linked OT
libraries do.
<
http://developer.apple.com/technotes/tn/tn1173.html>
My guess is that the real problem is as follows.
li r0,0
A: lwz r7,0(r3) // r7 = list.fHead
(r3 = 0x0A357A8E from the 'new' pool)
For PowerPC atomic operations to work properly the data must be
naturally aligned (4 byte quantities on 4 byte boundaries, 8 byte
quantities on 8 byte boundaries). This data (0x0A357A8E) is not
4-byte aligned. Ergo, the atomic operation doesn't work.
I don't know why this would only show up on Classic. The OT memory
allocator is supposed to return memory that's 4 byte aligned. If
it's not doing this properly under Classic, that's definitely a bug
on our part.
Regardless, you need to trace back where this value came from and
figure out why it's not aligned properly.
Natural aligned data also helps your performance.
Finally, when laying out data structures that include words that are
operated on atomically, you should remember that reservations are
maintained on a cache-line basis. This wasn't such a big deal on
G<=4 (the cache line size was 32 bytes), but it's much more important
on G5 (where the cache line size is 128 bytes). If you have an
atomic word that accidentally shares the same cache line as an
unrelated non-atomic word, you will increase the number of times you
have to spin to update the atomic word. This is even worse if you
have two atomic words on the same cache line.
Thus, in an ideal world you would manually allocate your OTLIFO
structures by calling OT to get a big chunk of memory, slicing that
up into cache line aligned and sized chunks, and suballocating those
slices for your application's OTLIFO needs. This is a pain, but the
only way to guarantee that each OTLIFO has a cache line to itself.
Naturally you should try to avoid hard-coding the cache line size. A
Mac OS X native application can get the cache line size from sysctl
or the I/O Registry. A traditional Mac OS application can get it
from the Name Registry. I'm not sure whether that works under
Classic.
OTOH you might want to avoid all this work until you've profiled your
application and seen that lock contention is a real problem.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.