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
e****d 发帖数: 895
6
Or maybe,
std::shared_ptr
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.
【在 e****d 的大作中提到】 : Or maybe, : std::shared_ptr
e****d 发帖数: 895
8
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
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
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
