On Jun 30, 2008, at 2:03 PM, nathan binkert wrote: >> The FastAlloc pools and StaticInst cache should clearly be >> duplicated. >> RefCounted will need some work though. I think the only problematic >> case is the EthPacketData and perhaps the statistics at the moment. > > Good call. > > What exactly is the problem with stats? They're for the most part > part of the class that defines them. Stats Nodes are refcounted, I don't know enough about how that works, but it seems like there could be a problem if you had a statistics that spanned threads.
> > As for RefCounted, I'll need to make a thread safe version that does > an atomic increment/decrement. It may turn out that using something > like auto_ptr is a better idea for some objects. Discipline about > only allowing certain objects to live on one thread at a time might > work too. Another option would be to have a boolean that said if it needed to be atomic or not. If you knew that the object wouldn't span threads it wouldn't need to be set or perhaps at the point when it changed threads it could be set. The logic needs to be a bit better than atomic inc/dec since you could possibly have double free case if you aren't careful. Ali _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
