Re: Thread safety

[Edward K. C. <ek...@lg...>]

On Feb 26, 2004, at 04:59, Dair Grant wrote:

> Edward K. Chew wrote:
>
>> My approach so far has been to do geometry manipulations in the thread
>> and then signal the main process to handle the rendering.  Being
>> paranoid, I defined a single global critical region across the entire
>> application to wrap around every set of calls to Quesa functions.
>
> 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.

Hmm...I would be in favour of this up to a point, as long as all this 
locking and unlocking doesn't add significant overhead.  Sure, it makes 
sense to keep someone from directly manipulating the view that's 
currently rendering, but would you really want to lock every last 
Submit call or accessor function under the assumption that some idiot 
is going to call a Get function from one thread at the same time as a 
Set from another?

I think for any API you are likely to use a hundred times in a loop, it 
would be better to expose the locking and unlocking functions and let 
people call them themselves.  I guess rendering loops and their ilk are 
already encapsulated by library calls, so you could just build the 
locking logic into them.

> 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.

FWIW, I would like to see geometry and display group manipulation off 
in its own module.  I think the retained mode is just made for 
multithreading!  What could be simpler than creating a display group in 
a thread, playing around with it liberally as much as you want, and 
only worrying about locking at very the last instant when you are 
assigning it to a view?

> 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).

Then how do you explain this?  :-)

> Host Name:      yinyang.local
> Date/Time:      2004-02-16 18:47:30 -0500
> OS Version:     10.3.2 (Build 7D24)
> Report Version: 2
>
> Command: MultiLoop III.carbon
> Path:    /Users/ted/Public/cvstree/mlp3/release/MultiLoop III.carbon
> Version: ??? (???)
> PID:     1772
> Thread:  1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000007
>
> Thread 0 Crashed:
> 0   MultiLoop III.carbon           	0x0053bcd8 0x405000 + 0x136cd8
> 1   MultiLoop III.carbon           	0x0053ba74 0x405000 + 0x136a74
> 2   MultiLoop III.carbon           	0x0053bfd8 0x405000 + 0x136fd8
> 3   MultiLoop III.carbon           	0x0053c6b4 0x405000 + 0x1376b4
> 4   MultiLoop III.carbon           	0x0053c750 0x405000 + 0x137750
> 5   MultiLoop III.carbon           	0x0051e458 
> allocmem__11xpmultitaskFUlRUc + 0x18
> 6   MultiLoop III.carbon           	0x004fce2c stdalloc__7xparrayFlRi 
> + 0x1c

[snip]

> Thread 1 Crashed:
> 0   MultiLoop III.carbon           	0x0053bcd8 0x405000 + 0x136cd8
> 1   MultiLoop III.carbon           	0x0053ba74 0x405000 + 0x136a74
> 2   MultiLoop III.carbon           	0x0053bfd8 0x405000 + 0x136fd8
> 3   MultiLoop III.carbon           	0x0053c6b4 0x405000 + 0x1376b4
> 4   MultiLoop III.carbon           	0x0053c750 0x405000 + 0x137750
> 5   MultiLoop III.carbon           	0x0051e458 
> allocmem__11xpmultitaskFUlRUc + 0x18
> 6   MultiLoop III.carbon           	0x004fce2c stdalloc__7xparrayFlRi 
> + 0x1c

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

-Ted