what race conditions can do

if you ever feel that there is a part of your code that might lead to a race
condition. don't u dare neglect it.
I had learnt this from a bad experience with alarm notification code for
evolution groupware. there was a call for alarm_init from two places
(one in the main loop and another in the bonobo factory initialization)
after checking on a condition if it is already inited or not ..
but the problem is that the two calls can be so near in time that it lead
to a race condition in which alarm_init gets called twice on the whole by
two different threads and all ........... yes indeed ... ALL the data structures
are duplicated .. The alarm notification was occupying double the memory
than it should have .. and the reason being negligence in checking for race
conditions ..
the fun part is that this problem surfaced in a seemingly independent way:
when an alarm notification is made ... each alarm summary was shown twice ...
since the alarm list is a static global list both the threads update it. with two
instances for a single appointment... Chen happened to trace back the problem
to this race condition and I have learnt an important lesson ..
"never mess with threads" (a parody of "never mess with pointers" heh ... )