Re: Thread safety

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

Edward K. Chew wrote:

>I am currently Carbonizing an old Quickdraw 3D app which did a lot of=20
>iterative updating out of the main event loop.  I want to move most of=20
>this logic into an MPTask, but am worried about the thread safety of=20
>the Quesa APIs.

At the moment, they're not:

<http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D902992&
group_id=3D45158&atid=3D442052>


>My approach so far has been to do geometry manipulations in the thread=20
>and then signal the main process to handle the rendering.  Being=20
>paranoid, I defined a single global critical region across the entire=20
>application to wrap around every set of calls to Quesa functions. =20

That is what you'd need to do: provided you have a single lock that
protects any Quesa API call, you should be fine.

Making the library thread safe would really be a two-step process:

1. Make there be a single lock inside Quesa that every glue method
acquires/releases.

2. Make there be multiple locks inside Quesa, so that multiple threads
can be inside the library at the same time.


The first one would let us declare the API to be thread-safe, so you
could use it from a thread and let your app code run in parallel with
itself (which will be where your 30% is coming from).

The second one is obviously the tricky case, but you could probably
introduce a lock per "module" (effectively source file, sinec most of
our types are opaque even internally) fairly easily.


>One concern I have is over memory allocation.  Does Quesa use NewPtr()=20
>to allocate retained-mode objects?

Quesa uses malloc, which will be thread safe if you're doing a Mach-O
build and normally not thread safe if you're using CFM (i.e., an MSL
which hasn't been rebuilt to be thread safe).

I believe NewPtr is (and always has been) thread safe on X, as it's just
a wrapper around malloc (with some extra book-keeping).


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