On Thu, Apr 7, 2011 at 5:29 PM, Gregory Farnum <gregory.farnum@xxxxxxxxxxxxx> wrote: > > On Thursday, April 7, 2011 at 5:21 PM, Colin McCabe wrote: >> I'm also aware that injectargs changes configuration values that other >> threads may be reading, without using a lock or an atomic update. So >> far, this doesn't seem to have created any problems, but it is >> technically incorrect and a worry. Probably the best way to resolve >> it is to construct a full copy of the configuration, change what is >> required, and then do an atomic swap on the g_conf pointer. > > I don't think this *can* cause any problems. There are no other writers to g_conf and, while I don't think we have nested checks (ie, branch based on g_conf, then assume g_conf remains static inside branch), even if we did then our single-dispatch mechanism means we're not going to have concurrent updates of that stuff. :) > On most architectures, 64-bit stores are not atomic, so if you're changing, say g_conf.objecter_inflight_op_bytes, there could be a brief window when someone could read half of the old value and half of the new value. I'm pretty sure that 64-bit stores end up being atomic on x86-64, if they're aligned, which gcc will always make sure of. However, if you're using x86 or arm, you're out of luck. Updating std::string structures is not atomic on any platform, to my knowledge. > I don't think we have nested checks (ie, branch based on g_conf, then > assume g_conf remains static inside branch), Sorry, we do! If you really need examples, look in the filestore and in the logging code. regards, Colin -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
