Subj : Re: Recursive lock? To : comp.programming.threads From : doug Date : Thu May 19 2005 09:46 pm "Michel" wrote in message news:1w5je.24748$d5.173573@newsb.telia.net... > doug wrote: >> Yeah, we wrap them up. We do this because we write our code to an >> 'isolation layer' api. We then write an isolation layer for each >> operating system, mapping the api calls to the primitives supported on >> that machine. >> >> It's not the fastest way to do it, but it's portable, and in debug builds >> we can add in code for things like: >> - double acquires >> - invalid frees >> - high contention (lots of threads waiting for some lock) >> - long holds (a thread holds a lock for a long time) >> - hierarchy checking >> >> Means we don't have to touch the app code when we port. >> > > Event though I work primarily in win32 land I wrap and isolate all apis as > well, for a lot of the reasons you mention, and to get a C++/exception > safe interface. Actually i don't see why It would hamper performance or be > as fast as native, at least not when diagnostics is compiled away. absolutely true - my mishtake! > But what typically does the wrapper do on double acquire (assert, throw) We assert and bring the server down. We get a stack trace of all threads and a core dump (on suitable OSs), and on a diags build we get information on who is holding what. (plus a load of other stuff.) We view things like this as coding errors, so kill the product asap, so there's no chance of missing it. > and what differences is there in debug and release builds? Well, there's a lot more code running when you do these debug checks. You have to lock around these checks too. All this adds up a rather different profile when you're running the code. It's good, but it's not rock solid - there's still a chance that a bug doesn't show up in debug testing due to the code differences, and doesn't show up in release builds until you ship it. Lovely. This type of bug would typically not be a double acuqire, invalid free, or hierarchy violdation - *as long as you cover every single code path in your debug testing*. Rather, it'd be a performance or scalability problem. Static analysis would solve all this, but is usually impossible for the places where it's really needed. For today. > > /Michel .