The way a CS seems to work in VFP, I think it would all boil down to which thread (if any) currently holds a single CS "token" that is shared among all of the VFP apartment threads in the process in which the MTDLL is loaded. In my situation, it would be IIS as the containing process. If apartment thread "A" holds the token and apartment thread "B" asks for it, it can't have it so B blocks. It seems that the VFP library would only need to use a single CS object for this, allocated in storage global to the DLL, and it would have to keep track of which threadID currently held the CS token, if any. Then it seems pretty straightforward to adjudicate things:
- If thread "A" holds the token and thread "B" asks for it, thread B blocks until A releases it.
- If thread "A" holds the token and thread "B" trys to release it by arbitrarily issuing a SYS(2336,3), the request should be ignored because B is not the current holder.

I don't think a critical section object has any use if it stored in thread local storage because the CS data structure must be shared among all participating threads. So I think the CS object must be allocated in storage global to the DLL. Maybe on the process heap?

>Hi Jim,
>
>>Issues like this should have been in the documentation in the first place.
>
>I agree. Alternatively, you could use the API functions directly. Fortunately, the VFP documentation points to the correct API functions.