views:

31

answers:

2

I am refining a large body of native code which uses a few static critical sections and never calls DeleteCriticalSection, leaving them to process exit to clean up.

There are no leaks and no concerns about the total number of CS getting too high, I'm just wondering if there are any long-term Windows consequences to not cleaning them up. We have regression test suites that will launch a program thousands of times a day, although end users are not likely to do anything like that.

Because of the range of deployed machines we have to consider Windows XP as well and this native code is run from a managed application.

+1  A: 

A critical section is just a block of memory unless contention is detected, at which time an event object is created for synchronization. Process exit would clean up any lingering events. If you were creating these at runtime dynamically and not freeing them, it would be bad. If the ones not getting cleaned up are a fixed amount for each process, I wouldn't worry about it.

In principle, every process resource is cleaned up when the process exits. Kernel resources like event objects definitely follow this principle.

Chris Smith
Thanks for the reassurance.
Andy Dent
+1  A: 

The short answer is probably not. The long answer is, this is a lazy programming practice and should be fixed.

To use DeleteCriticalSection correctly, one needs to shutdown in an orderly manner so that no other thread owns or attempts to own the section before/after it is deleted. And programmers get lazy to define and implement how shutdown will work for their program.

There are many things you can do with no immediate measurable consequences - but that does not make it right. Also similar attitude towards other handles/objects in the same code base will have cumulative effect and could add up to "consequences".

Winprogger
agreed it's a bit sloppy and I have a long list of code cleanups I'm planning ;-)
Andy Dent