Re: [Vala] Locking null references

["Jan Hudec" <bulb ucw cz>]

On Tue, March 30, 2010 11:47, "Andrés G. Aragoneses" wrote:

> > decided to use different lock statement semantics compared to C#. The
> > only other option would have been to not support lock statements at
> > all .
>
> Well, I'm wondering about a 3rd option which would be a compromise: that
> vala translate every lock statement with a minimal null-check first, so
> if the condition is not met, an exception is raised? What do you think
> about this approach?

Utterly, absolutely wrong. As long as it locks the field, it should lock
it no matter what value it has. It is not guarding against change in the
refered object anyway!

> [...]
> > Yes, it's unfortunate that we can't properly support lock(this) as
> > GObject doesn't support it and we can't just add a mutex field to
> > instance structs as this would result in issues when using lock(this) in
> > subclasses. Otherwise, I'd probably recommend using lock(this) in most
> > cases.

Since most objects won't ever need to be used with lock() (in any language),
it's IMHO bad design to have a universal lock statement working with
anything.

Personally I am not sure lock() is a reasonable thing to do. IMHO too many
(all) things being lockable just make it easier to forget what should be
locked when. For me, using() statement working with Mutexes seems sufficient.

Alternatively it should be possible to implement Monitor without needing
a member in the synchronized object (I would expect CLR to actually do it
that way, because the overhead for having mostly unused mutex in every
object would be quite high). A simple idea is to have a collection of the
currently locked objects with a condvar. A simple implementation would be
slow because of the global lock, but a mostly efficient implementation should
be doable (though system-specific).

-- 
                                        - Jan Hudec <bulb ucw cz>