Re: profiling multi threaded applications

I don't have anything against lockstep mode, if it's automagically 
forced only during profiling, but I don't want to design the app to work 
that way during normal operation. The reason is that if these steps are 
not fine enough, it could hurt interactivity, which I can live with 
while profiling, but cannot accept in "final" mode.


brian sharon wrote:
> Andras, are all of your threads doing the same thing? Otherwise, a critical 
> section won't do anything for you. If only one thread tries to acquire the 
> object, it will (trivially) always get it.
> 
> Now, if you're thinking going to put this critical section at the top level 
> of your app and make all threads go through it, then you're back to 
> Christian's suggestion:
> 
> If possible, design your architecture so that your threads can work in a
> lockstep mode, with one central mutex controlling which thread is running at
> any given moment. That way you can at least get a partial profile and
> optimize each thread individually.
> 
> This type of design can also prove very useful to debug deadlocks.
> 
> --brian
> 


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557