Re: eiffel parser in SmartEiffel

> Also you should consider to dive into the world of lock-free
> programming where the huge benefit is not performance (as many people
> think) but deadlock free programming. This seems to became serious
> now, fundamentals were added to Java 1.6 and just these days Intel put
> their TBB (thread building block) library under GPL(+Runtime
> Exception). So we finally have some code to look at. Lock-free
> programming is unfortunately not widely implemented and full of
> patents, so you can't find a lot of open source code. You need to read
> state-of-the-art papers and write this your own. But once you
> understand how it works it is not impossible.
>
Thanks for the pointer to the Intel tools.  I skimmed some of the
do***entation
today but did not see a reference to lock-free programming.  I did see
the
Intel site mention mutexes, etc.  And I have never heard of lock-free
programming.
So, I looked it up on Wikipedia.  Not always the most successful
approach, but
usually the quickest and most direct. :-)  Anyway, they noted the
following:

   "Lock-free" refers to the fact that a thread cannot lock up: every
step it takes brings progress to the system. This means that no
synchronization primitives such as mutexes or semaphores can be
involved, as a lock-holding thread can prevent global progress if it
is switched out. "Wait-free" refers to the fact that a thread can
complete any operation in a finite number of steps, regardless of the
actions of other threads. All wait-free algorithms are lock-free, but
the reverse is not necessarily true. (from Wikipedia)

And when I read through some examples, it looks like lock-free
algorithms are
using one of my favorite design patterns: transactions.  That is, with
a
transaction you try to have each unit of the transaction execute
atomically.
With atomic execution, either the whole action succeeds or the whole
action
fails.  The same article noted that often the hardware provides a
"compare
and swap" feature that enables a thread to determine if a value is
either updated (atomically) or whether the value has failed to update
because some other thread has already updated the value.

Is this your understanding of lock-free or did I miss something? Let
me know
and then I can give you my 2 cents on how some of these ideas might
be achieved with SmartEiffel 2.3.

Lee