[PEAK] Re: Trellis-fork

[Sergey Schetinin]

On 2009-06-24, P.J. Eby <pje at telecommunity.com> wrote:
> At 12:25 PM 6/23/2009 +0300, Sergey Schetinin wrote:
>
> > The problem with this is that if different cells have different locks
> > as their managers the deadlocks are very likely. There's no way of
> > telling what cells will be used in a transaction and in what order so
> > two concurrent transactions are very likely to get into a deadlock.
> >
> > If all cells have the same lock as their manager there are no
> > deadlocks, but the whole ctrl.lock() business is pointless as there's
> > only one lock to acquire and release.
> >
> > Another possible case is when there are two or more sets of cells that
> > form disjoint networks. All cells in each of these sets would have the
> > same lock. This way there's a guarantee of no deadlocks, but the only
> > reason to use locks in this case is if there will be concurrent
> > transactions on the same cell network.
> >
>
>  You've missed the idea behind the design, which was that the "manager" of
> the cells is a single thread-specific object, shared between all cells
> created in that thread.  Thus, cells created by a thread share a single
> lock, thereby reducing the possible ways of deadlocking.
>
>  In fact, as long as there are not bidirectional observations taking place
> between threads, deadlock should be impossible.  That is, if you have, say,
> worker threads that produce or consume data in queues owned by the workers,
> and there are other processes that put things in the queues or take them
> out, the workers are never acquiring locks on their clients, and thus cannot
> deadlock.
>
>  The net effect is GIL-like, except that it allows essentially isolated
> threads to run freely, with pauses only happening when inter-thread
> communication happens.

Sure, this would work as long as there are no circularities between
threads, but if there are, there would be a deadlock. Just a little
slip, just one cell being read in the wrong thread and one gets a
possibility deadlock, given how hard it would be to diagnose such a
problem, I'd rather pay the price of global lock.

Also, the cells used in certain thread would absolutely have to be
created in that thread which is another source of deadlocks.

>
> > If not atomic there's no guarantee of getting valid value which isn't
> > easily resolved.
> >
>
>  I don't think that's within design scope, since untransacted reads are
> inherently a volatile sampling.  Without a transaction, you can't guarantee
> that the next read won't have changed, anyway!

The problem IMO is that the read value is not just volatile, it could
be entirely invalid, that is no committed transaction would ever
result in that cell having that value, but while txn runs the cells
could at time have these values that are immediately rolled back, and
other thread might see it while it's still there.


-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter