Ben Hutchings wrote:
John Torjo <john.lists@torjo.com> wrote:
Alexander Terekhov wrote:
John Torjo wrote: [...]
Whenever a thread (other than main) wants to access this window, it will query the weak_pointer. The weak_pointer needs to know the LATEST reference count in order to know if the weak pointer is still valid. Thus, atomic_read that simply returns the value is not enough.
However, the weak_ptr doesn't just use atomic_read. If atomic_read returns 0 that means the use count has dropped to 0 [*] and can never increase again, so it must be the latest version. Otherwise weak_ptr makes a second test that is properly protected. So it can never use an old value.
yes, that is quite right.
This is still unaccessible. why don't you mail the code to Alexander and me (or to the list, in case anyone else is interested)?
done that. See my other post.
class test { ... };
[thread1] shared_ptr<test> p1( new test); // refcount = 1
---------------- thread switch
Switches between threads running on a single processor can't cause problems here, because the use of "volatile" ensures that the compiler won't reoder access to the use count and the processor will only reorder memory access in a way that is invisible to the code it's running. There might conceivably be problems that occur when multiple threads run concurrently on multiple processors, in which
as a side note, my PC is already a dual-processor ;)
case reordering by one processor can affect another. So I'll ignore the "thread switches".
I just used the "thread switch" to make a point ;)
[thread2] shared_ptr<test> p2(p1); // refcount = 2 weak_ptr<test> weak(p2); p2 = shared_ptr<test>(); // refcount = 1
------------------thread switch [thread1] p1 = shared_ptr<test>(); // refcount = 0 - object gets destroyed ---------------- thread switch [thread2]
// here - you need InterlockedCompareExchange // to realize that refcount is 0 (zero) shared_ptr<test> p3 = weak.lock();
expired() may read the count as still being 1 and so return false, but I believe the wnd_shared_ptr constructor will catch the fact that the pointer really has expired. Unfortunately I can't yet see the code to confirm this!
By looking at the code, I would think not. But I may be wrong. Anyway, I've posted the code in my other post. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)