quote:
ur a true poet 
ok, to review:
- need locking on ref counting base
- this gives us status flag indicating enviroment type
- based on this flag, get/set functions for our data can work with or without internal locking, so the unneeded overhead is actually gone, right?
If you set the flag in the ctor and it''s constant, then yes. If the flag can change, then this won''t work (race condition).
If you set the flag in the ctor and it''s constant (cannot change in the object''s lifetime), then you can implement it the way you are talking about with only the overhead of a couple of if statements.
If the flag can change, then you must always lock anyways, just in case the flag is changed while you are accessing it. Changing the flag also needs to be locked so you can''t have an inconsistent state! (someone using it in a STA, and someone ready to use it in a MTA)
quote:
one more thing:
if one piece of data is too popular and is geting a lot of race conditions, would it be wise to make a second copy of, so that "work" would distribute?
If it''s read-only access then you can lock, make a local copy, and unlock. If you mutate the data, then you need to hold the lock the whole time. You have to take care that you don''t introduce race-conditions trying to optimize the performance.
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
