From: Robert Dober <robert.dober@...>
Date: 2007-05-18T04:30:41+09:00
Subject: Re: "Crystallizing" Objects

On 5/17/07, Yohanes Santoso <ysantoso-rubytalk@dessyku.is-a-geek.org> wrote:
> Sven Suska <sven715rt@suska.org> writes:
>
> > Sven Suska schrieb:
> >
> > If it were just a normal hash, we would have to lock the object manually:
> >
>
> Start locking from this point, before you do a check.
>
> >  if users.has_key(new_nickname)
> >    raise "Nickname already exists"
> >  end
> >  # hash could be modified here, if not locked!!!
> >  # if another thread would have stored a user with the same nickname
> >  # just now, then this data would be overwritten in the next
> >  statement.
>
> If you start locking at this point, then in between the check and the
> insertion another check and insertion could have occurred and the
> following insertion effectively undoes that insertion.
>
> >  users[new_nickname] = user_data
>
>
> > If "users" were in this "partially_frozen" state, then we could write:
> >
> >  begin
> >    users[new_nickname] = user_data
> >  rescue CantChangeExistingDataError
> >    raise "Nickname already exists"
> >  end
>
> For Hash in official ruby implementation, since #= is implemented in C
> without any yielding, #= is effectively an atomic operation. But since
> you want to throw an exception if there is already existing entry, you'd
> still need a lock to do the check-and-insert atomically.

I see this point now, I totally forgot what OP wanted this for, easy
synchronization.
I doubt that this is possible, R/W locks would do the same and of course <<
would need a Write lock even if it "only" creates a new key.

FWIAC I thought the concept of demi-frozen object state avoiding any
information loss was interesting on a theoretical base, not for
synchronization.
>
<snip>
>
> YS.
>
>
R.

--