Re: [tlug] STM (was: Re: work times & accommodation @tokyo)

[Attila Kinali <attila@example.com>]

On Mon, 28 Jul 2008 07:30:43 +0900
Curt Sampson <cjs@example.com> wrote:

> > Does STM work in real world applications?
> 
> I can see no reason why it wouldn't. Keep in mind, it's not very
> different from standard locking that most threaded applications are
> using already; STM in combination with other things in Haskell just
> allows you to easily compose your locking primitives and type-check
> their composition.

I could see a couple of reasons why STM cannot work the first
time i read about it. So this argument "why shouldn't it" is
pretty much void.

As an example, imagine two tasks doing some work on exactly the
same data set in a loop, over and over again. Task B takes longer
than task A to finish its work.

Because at the time when task A commits, B's input will have
changed it must abort its operation and restart. But because
A already started with the next run, A will finish before B
does and thus B will have to abort/restart its work again.
ad inifitum.
(ie the simple task A starves task B example)

With conventional locking this can be avoided given a
proper locking strategy (ie without changing the algorithm).
I cannot see how this can be avoided with STM.


				Attila Kinali
-- 
The true CS students do not need to know how to program.
They learn how to abstract the process of programming to
the point of making programmers obsolete.
		-- Jabber in #holo