Depends on the underlying implementatin, for example,
it's an issue for java 1.4, not for 1.5 or above.
【在 e****d 的大作中提到】 : Will it introduce any race condition?
t****t 发帖数: 6806
3
其实这个东西本身的思想没问题, 关键是实现者往往忽略一个问题: 如果一个object需
要在lock(synchonized, in java)之外concurrent access, 那它应该是atomic的. 如
果忽略了这个问题那就是bug.
【在 g*****g 的大作中提到】 : Depends on the underlying implementatin, for example, : it's an issue for java 1.4, not for 1.5 or above.
e****d 发帖数: 895
4
Anything wrong with this assuming do_something() doesn't modify its
object?
std::mutex m;
std::shared_ptr
t****t 发帖数: 6806
5
刚好最近写了一些多线程的东西, 自己也研究了一下, 多写几句.
yes, the problem is shared_ptr<> itself may not be lock-free (and atomic
automatically). so it's possible that when doing
p=shared_ptr(new Object); // why not write p.reset(new Object)?
p may be in an intermediate indetermined state. it's possible that p get
accessed during this state and you are in race condition.
However, since you used shared_ptr, you can use it's accompanying atomic
store for this purpose (not fully implemented in libstdc++ yet)
atomic_store(&p, shared_ptr(new Object));
and corresponding load. But the problem is, if it's not lock-free, you lose
the benefit of double-checked locking. there are two solutions to this, (a)
don't use shared_ptr, and just use atomic p, and p=new Object shall
be atomic automatically. but you need to release the resource yourself. (b)
use an atomic guard, e.g.
mutex m;
shared_ptr p;
atomic_bool initialized(false);
if (!initialized) {
lock_guard l(m);
if (!initialized) {
p.reset(new Object);
initialized=true; // this guarantees p is fully settled
}
}
【在 e****d 的大作中提到】 : Anything wrong with this assuming do_something() doesn't modify its : object? : std::mutex m; : std::shared_ptr p; : if (!p) : { : std::lock_guard l(m); : if (!p) : p = std::shared_ptr(new Object); : }
e****d 发帖数: 895
6
Or maybe,
std::shared_ptr p;
std::once_flag f;
std::call_once(&f, [](p.reset(new Object)));
p->do_something();
lose
【在 t****t 的大作中提到】 : 刚好最近写了一些多线程的东西, 自己也研究了一下, 多写几句. : yes, the problem is shared_ptr<> itself may not be lock-free (and atomic : automatically). so it's possible that when doing : p=shared_ptr(new Object); // why not write p.reset(new Object)? : p may be in an intermediate indetermined state. it's possible that p get : accessed during this state and you are in race condition. : However, since you used shared_ptr, you can use it's accompanying atomic : store for this purpose (not fully implemented in libstdc++ yet) : atomic_store(&p, shared_ptr(new Object)); : and corresponding load. But the problem is, if it's not lock-free, you lose
t****t 发帖数: 6806
7
well this depends on call_once implementation. i heard on pthread it does
use double checked locking, but sometimes it's broken.
Does accessing atomic_bool variables guarantee
memory order? If not, your example requires memory fences.
lose
【在 t****t 的大作中提到】 : 刚好最近写了一些多线程的东西, 自己也研究了一下, 多写几句. : yes, the problem is shared_ptr<> itself may not be lock-free (and atomic : automatically). so it's possible that when doing : p=shared_ptr(new Object); // why not write p.reset(new Object)? : p may be in an intermediate indetermined state. it's possible that p get : accessed during this state and you are in race condition. : However, since you used shared_ptr, you can use it's accompanying atomic : store for this purpose (not fully implemented in libstdc++ yet) : atomic_store(&p, shared_ptr(new Object)); : and corresponding load. But the problem is, if it's not lock-free, you lose
g*********s 发帖数: 1782
9
有啥MT参考书吗?想做点练习。
lose
【在 t****t 的大作中提到】 : 刚好最近写了一些多线程的东西, 自己也研究了一下, 多写几句. : yes, the problem is shared_ptr<> itself may not be lock-free (and atomic : automatically). so it's possible that when doing : p=shared_ptr(new Object); // why not write p.reset(new Object)? : p may be in an intermediate indetermined state. it's possible that p get : accessed during this state and you are in race condition. : However, since you used shared_ptr, you can use it's accompanying atomic : store for this purpose (not fully implemented in libstdc++ yet) : atomic_store(&p, shared_ptr(new Object)); : and corresponding load. But the problem is, if it's not lock-free, you lose
e****d 发帖数: 895
10
You can read some src code about that. One example is
boost::share_ptr, which uses atomic operations.
【在 g*********s 的大作中提到】 : 有啥MT参考书吗?想做点练习。 : : lose
t****t 发帖数: 6806
11
if you can just go ahead and read c++0x draft...
【在 e****d 的大作中提到】 : Does accessing atomic_bool variables guarantee : memory order? If not, your example requires memory fences. : : lose
P********l 发帖数: 452
12
哪里能拜读一下大作?
lose
【在 t****t 的大作中提到】 : 刚好最近写了一些多线程的东西, 自己也研究了一下, 多写几句. : yes, the problem is shared_ptr<> itself may not be lock-free (and atomic : automatically). so it's possible that when doing : p=shared_ptr(new Object); // why not write p.reset(new Object)? : p may be in an intermediate indetermined state. it's possible that p get : accessed during this state and you are in race condition. : However, since you used shared_ptr, you can use it's accompanying atomic : store for this purpose (not fully implemented in libstdc++ yet) : atomic_store(&p, shared_ptr(new Object)); : and corresponding load. But the problem is, if it's not lock-free, you lose