Re: Promoting weak pointers

Michiel Helvensteijn <m.helvensteijn@gmail.com>
Tue, 16 Jun 2009 06:55:57 -0700 (PDT)

          From comp.compilers

Related articles
Promoting weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2009-06-11)
Re: Promoting weak pointers fset.slb@gmail.com (Scott Burson) (2009-06-15)
Re: Promoting weak pointers andrew@tomazos.com (Andrew Tomazos) (2009-06-16)
Re: Promoting weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2009-06-16)
Re: Promoting weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2009-06-16)
Re: Promoting weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2009-06-17)
Re: Promoting weak pointers bobduff@shell01.TheWorld.com (Robert A Duff) (2009-06-17)
Re: Promoting weak pointers andrew@tomazos.com (Andrew Tomazos) (2009-06-18)
Re: Promoting weak pointers armelasselin@hotmail.com (Armel) (2009-06-19)
Re: Promoting weak pointers dot@dotat.at (Tony Finch) (2009-06-19)
| List of all articles for this month |

From: Michiel Helvensteijn <m.helvensteijn@gmail.com>
Newsgroups: comp.compilers
Date: Tue, 16 Jun 2009 06:55:57 -0700 (PDT)
Organization: Compilers Central
References: 09-06-047 09-06-055
Keywords: linker, parallel
Posted-Date: 17 Jun 2009 03:38:02 EDT

On Jun 16, 12:39 pm, Andrew Tomazos <and...@tomazos.com> wrote:


> One reason you may want to promote a weak reference to a strong
> reference is under contention from different thread contexts. In fact
> where there is contention, the system should *require* promotion
> before dereferencing.
>
> Consider:
>
> if (my_weak_ptr != NULL)
> my_weak_ptr->do_something();
>
> Here if my_weak_ptr's target is garbage collected in another thread
> between the test and when it is used than you are going to dereference
> null.
>
> Better to:
>
> my_strong_ptr = my_weak_ptr;
> if (my_strong_ptr != NULL)
> my_strong_ptr->do_something();
>
> That way the strong reference will provide protection for the critical
> section of code.


I did not consider threaded applications, mostly because we are mainly
focussing on sequential applications in Mist. But your point remains
valid, nonetheless.


However, I would argue that weak pointer promotion is in this instance
only a workaround for ensuring the isolation of your pair of
operations (testing for null and dereferencing). You did not really
want to keep the object alive. You merely wanted to interact with the
object iff it exists, which should be possible with a weak pointer.


It would perhaps be better if the programmer were able to set and
release a lock against destruction at the location of the object, yet
still use a weak pointer. I have not thought this through in detail,
though.


> [In every system I've seen with strong and weak pointers, the pointer
> values are all either filled in or not before the program starts. I
> suppose there might be race conditions if you do dynamic linking, but
> that's a separate issue. -John]


I'm not sure I'm following you, John. The pointers I'm talking about
can be made to point to other objects during the lifetime of the
program. Their value is not fixed at its beginning.
[Now I'm confused, too. This is an ordinary race condition of the kind
that every parallel program has to handle, and would present the same
issues no matter what kind of pointer it is. -John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.