Uhaw Pa Sa Camel

 
d'Doc
Alabang, Muntinlupa City, Philippines
Beer-loving Gunner extraordinaire, perennial vocalist, guitarist, dog person, and wet kisser in one neat li'l package.

>> VIEW MY COMPLETE PROFILE

 

Subscribe to
Posts [Atom]  

Previous Posts

Powered by Blogger

 
Sunday, November 22, 2009

Macros are Evil, a Multi-Threaded Scenario

 
The daemon I mentioned in my preceding post did fail some debug assertions which I found out came from the U++ MAP containers. Now this confirms my suspicion that there was a race condition in my app which puts the container in a "volatile" state. Digging though my code I found out that this code:

#ifdef GUI_POST_CALLBACK
#define MUTEX_LOCK(mutex)   Mutex::Lock __(mutex)
#else
#define MUTEX_LOCK(...)   ((void)0)
#endif

should have been:

#ifdef GUI_POST_CALLBACK
#define MUTEX_LOCK(...)   ((void)0)
#else
#define MUTEX_LOCK(mutex)   Mutex::Lock __(mutex)
#endif

Let me explain. Posted callbacks (using U++ PostCallback() in GUI mode) are called with mutex locking automatically done by the U++ framework. Since a daemon is not a GUI app, GUI_POST_CALLBACK is not defined, which leaves me to create my own locking. In the incorrect code above the ifdef guard was reversed thus calling MUTEX_LOCK(mutex_) had no effect in my code, leaving the daemon code vulnerable to non-preemptive data sharing! Reversing it solved the problem. No more crashing!

Whew, definitely NOT python + twisted! :D

Subscribe to
Posts [Atom]

 
 

0 Comments:

Post a Comment

<< Home