Re: CSingleLock - known behaviour?
On Thu, 26 Jun 2008 12:37:49 -0700 (PDT), neilsolent
<neil@solenttechnology.co.uk> wrote:
While I appreciate your comments - remember you just asked me to
provide an example.
That is all this was! This is not my actual code.
Your pseudocode only raised the questions I gave in my last message.
Thinking about it some more, the following elaboration of your pseudocode
would be valid given a recursive lock class:
void my_free(void* p1, void* p2)
{
CSingleLock lk(&mx_heap, FALSE);
if (p1) // ( ...condition1 ..)
{
lk.Lock();
my_free_nolock(p1);
}
if (p2) // ( ...condition2 ..)
{
lk.Lock();
my_free_nolock(p2);
}
}
I don't think it's worthwhile to micromanage the locking in that way, but
the code is correct; the things I discussed in my last message do not apply
to it. However, this approach is still more verbose, complex, and fragile
under maintenance than locking the whole function, and any performance gain
is likely negligible, so by default, I would write:
void my_heap_free(void* p1, void* p2)
{
CSingleLock lk(&mx, true);
my_heap_free_nolock(p1); // This function also tests for NULL.
my_heap_free_nolock(p2);
}
--
Doug Harrison
Visual C++ MVP