>> In those functions, the code I cut out is a memory based version of the same thing that doesn't hit critical sections at for the very reasons you cited <<
Just to clarify: the use of critical sections, in and of themselves, is not a problem (in this scenario). It was that in that particular situation, the "interior" (the hold time) of the CS was far from minimized, and thus would elicit worst case CS behavior on top of the already involved file system operations. One loses the performance benefits of CS's, pretty much turning the CS into a full (slower, context switching) mutex every time. It would seem that using a CS to protect memory-based assets (in the other version) would be rather necessary... >> I definitely think you have been reading up on your threading << Heh... It's been a while. And with my head buried deep in other problems it feels almost as rusty as the snowblower that needs to get prepped for the impending snow storm... >> I also didn't use a stack for the file stuff ... << I don't get what you mean here. The stack would just have been "memory-based" and used to confirm that out calls matched in calls. The output destination wouldn't actually matter at all, and could in fact be run-time switchable, and so on... Since the whole point of the in and out logging is to help debugging, "failing fast" (when failing) would be very useful, and would pinpoint the problem much quicker. If the in/out logging system complains that the last out call doesn't match the last in call, you know *right there's* a problem--probably fairly often that one just forgot to add the right diagnostic in or out calls... ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
