Hi Mark,

I don't know for sure how SYS(2336) is implemented but I believe that it creates one "process global" CS object. Otherwise it had to provide some way to create and pass CS objects around which it doesn't. You're correct that externaly CS works exactly as mutex but is slightly faster.

>I understand that material (had already read it). What is opaque is just how VFP is actually implementing those CS API calls. Per the info on that web page, within a process one can apparently create any number of critical section objects and use each of them as synchronization objects for individual sections of code (wherever/however the programmer wants). Or you can create just _one_ CS object and use it as a generic synch controller throughout your code... however, if you do so, then all other threads in the process are potentially blocked from _any_ critical sections that also use that same generic CS object for synchronization, and this blocking occurs even if one such critical section has no dependency upon another such critical section elsewhere in your code. Using a generic CS object is like a "poor man's synch object" approach because, while it works, it can cause unnecessary blocking at times. I think that this is what VPF is doing. In my mind, conceptually the same as
>allocating a single mutex (the name of which is only internally known) for the process, and using that single mutex for all CS management regardless of how many different critical sections you have in your code and also regardless of how interdependent those sections might (or might not) be.
>
>Does this make sense? I know what I want to ask, but I'm kind of floundering with how to ask it.