Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

about concurrency (again)

1 view
Skip to first unread message

michele....@gmail.com

unread,
Nov 19, 2007, 1:32:50 AM11/19/07
to
I have been reading the recent thread about concurrency, which is
unfortunately
for the most part over my head, and I wanted to assess what I
understand
of concurrency (or I think I understand).
In particular I wanted to make clear what do you mean for message
passing
and what is the name for the model I have in mind, since I actually
lack a formal
training on concurrency. I will make a very simple example to make
things
crystal clear; please forgive me if I am too pedagogical.

Suppose I am testing a software for launching nuclear missiles (this
is
just to make things a bit more melodramatic;). I will have routines
like the following (let me use Python, since I am more confortable
with it):

safe_mode = True

def enable_safe_mode():
global safe_mode
safe_mode = True

def disable_safe_mode():
global safe_mode
safe_mode = False

def launch_nuclear_warhead():
if safe_mode:
print 'Just emulating the launch of a nuclear warhead'
else:
print 'You just launched a nuclear warhead!'

def test_launch():
enable_safe_mode()
launch_nuclear_warhead()

When I call test_launch, nothing bad happens, since I have enabled the
safe_mode flag and I feel confident that my code has no bugs.
Suppose now that a collegue of mine is doing tests with the safe_mode
setting routines:

def test_safe_mode():
try:
disable_safe_mode()
finally:
enable_safe_mode()

Notice that my collegue is very careful to re-enable the safe mode
after he
tested disable_safe_mode, so he is also confident that his code has no
bugs.
Both routines are actually correct for non-concurrent code, but they
are buggy in presence of concurrency. Actually if both test_launch
and test_safe_mode run simultaneously the following scenario may
happen,
in a non-deterministic way:

1. in test_launch enable_safe_mode is called;
2. in test_safe_mode disable_safe_mode is called;
3. in test_launch launch_nuclear_warhead is called;
4. the warhead is fired!
5. in test_safe_mode enable_safe_mode is called, but too late :-(

How do we avoid firing the missile? The usual solution is to put locks
everywhere but it is clearly too invasive. What I would do (and I
would
like to know how this approach is called in the literature) is to
introduce
a message_manager object which dispatches to the right routines and
takes care of the locks in a centralized way. One possible
implementation
could be the following:

def message_manager():
while True:
with threading.Lock():
message = yield
message()

# "instantiate" the manager in the main thread
manager = message_manager()
manager.next()
# send messages like manager.send(test_launch)

Now different threads can send to the manager a message (the message
is the routine the manager should call) and be assured that the
messages will be processed sequentially. Basically the manager is
converting back the critical parts of the application to single-
threaded
mode. The same discussion clearly applies to independent process,
where
the safe_mode flag could be stored in a file or in a database and
the lock could be a file lock or a transactional lock.

How would you improve over this solution and what would you
recommend?
Concrete examples are welcome!

Michele Simionato

David B. Benson

unread,
Nov 19, 2007, 1:28:15 PM11/19/07
to
On Nov 18, 10:32 pm, "michele.simion...@gmail.com"
<michele.simion...@gmail.com> wrote:
...
> Michele Simionato

John Reppy's "Concurrent Programming in ML" is being re-issued in
paperback by Cambridge University Press.

Jon Harrop

unread,
Nov 23, 2007, 8:10:54 PM11/23/07
to

Is it not out of date these days?

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u

Neelakantan Krishnaswami

unread,
Nov 23, 2007, 9:37:16 PM11/23/07
to
In article <<13kev1d...@corp.supernews.com>>,

Jon Harrop <use...@jdh30.plus.com> wrote:
> David B. Benson wrote:
>> On Nov 18, 10:32 pm, "michele.simion...@gmail.com"
>> <michele.simion...@gmail.com> wrote:
>> ...
>>> Michele Simionato
>>
>> John Reppy's "Concurrent Programming in ML" is being re-issued in
>> paperback by Cambridge University Press.
>
> Is it not out of date these days?

No, it's not.


--
Neel R. Krishnaswami
ne...@cs.cmu.edu

David B. Benson

unread,
Nov 24, 2007, 2:43:14 PM11/24/07
to
On Nov 23, 5:10 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
> ...

> Is it not out of date these days?

Don't be silly. CUP wouldn't issue a (corrected) paperback version in
that case.

Jon Harrop

unread,
Nov 24, 2007, 10:29:24 PM11/24/07
to

Aren't CUP famous for selling out of date books (e.g. Numerical Recipies)?

Vesa Karvonen

unread,
Nov 25, 2007, 5:54:27 AM11/25/07
to
Jon:

> David B. Benson wrote:
> > On Nov 23, 5:10 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
> >> ...
> >> Is it not out of date these days?
> >
> > Don't be silly. CUP wouldn't issue a (corrected) paperback version in
> > that case.

> Aren't CUP famous for selling out of date books (e.g. Numerical Recipies)?

http://en.wikipedia.org/wiki/Fallacy_of_many_questions
http://en.wikipedia.org/wiki/Ignoratio_elenchi
http://en.wikipedia.org/wiki/Argumentum_ad_baculum
http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt
http://en.wikipedia.org/wiki/Logical_fallacy

-Vesa Karvonen

Alexander Schmolck

unread,
Nov 25, 2007, 9:01:54 AM11/25/07
to
Jon Harrop <use...@jdh30.plus.com> writes:

> David B. Benson wrote:
>> On Nov 23, 5:10 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
>>> ...
>>> Is it not out of date these days?
>>
>> Don't be silly. CUP wouldn't issue a (corrected) paperback version in
>> that case.
>
> Aren't CUP famous for selling out of date books (e.g. Numerical Recipies)?

The latter having famously been superseded by ...?

'as

Jon Harrop

unread,
Nov 25, 2007, 12:32:27 PM11/25/07
to
Alexander Schmolck wrote:
> The latter having famously been superseded by ...?

NR hasn't been superceded AFAIK. Someone should probably do that at some
point. In the mean time, you'll find current information in more specific
places.

The NR section on FFTs has no citations from the past 15 years, for example:

"There are also FFT algorithms for data sets of length N not a power of
two... Our advice is to stay clear of such FFT implementations."

This has been out of date for the best part of a decade. The FFT routines in
MATLAB and Mathematica both use the approach that NR advises against
precisely because it is both much faster and much more accurate.

While the authors of NR had a good breadth of knowledge their software
engineering practices are awful. Only their Fortran code could be
considered good, much of their C code isn't even valid:

http://groups.google.com/group/comp.std.c/msg/c0341252c149f500

and NR in C++ is a joke, of course.

Fortran programmers are now the minority in technical and scientific
computing.

David B. Benson

unread,
Nov 25, 2007, 2:01:20 PM11/25/07
to
On Nov 24, 7:29 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
...
>
> Aren't CUP famous for selling out of date books (e.g. Numerical Recipies)?


NR is now in its third edition. We might hope it is better than the
earlier ones.

Out-of-date for a publisher means they can't sell it anymore.
So it seems that CUP believes that enough people will want
John Reppy's book to re-issue it. Also for NR3...

Jon Harrop

unread,
Nov 25, 2007, 2:08:55 PM11/25/07
to
David B. Benson wrote:
> Out-of-date for a publisher means they can't sell it anymore.
> So it seems that CUP believes that enough people will want
> John Reppy's book to re-issue it. Also for NR3...

CUP is a not-for-profit charity so they are less interested in trifling
concerns like profit. As an author and publisher myself I have dealt with
many publishers including CUP and I can tell you that CUPs motivations are
quite atypical for a publisher. This is a welcome break in terms of
publishing books on obscure subjects that do not sell well but it does mean
that CUP's books do not reflect the state-of-the-art.

David B. Benson

unread,
Nov 25, 2007, 2:19:30 PM11/25/07
to

David B. Benson

unread,
Nov 25, 2007, 5:52:17 PM11/25/07
to
On Nov 25, 11:08 am, Jon Harrop <use...@jdh30.plus.com> wrote:
...
> CUP is a not-for-profit charity
...

> that CUP's books do not reflect the state-of-the-art.

Unless there is an endoyment or stipend, CUP cannot afford continual
losses.

Perhaps rather than 'state-of-the-art' a better term is
'merely popular'?

Paul Rubin

unread,
Nov 25, 2007, 6:31:59 PM11/25/07
to
"David B. Benson" <dbe...@eecs.wsu.edu> writes:
> Unless there is an endoyment or stipend, CUP cannot afford continual losses.

If you know what the U in CUP stands for, that might complete the picture.

David B. Benson

unread,
Nov 25, 2007, 7:15:22 PM11/25/07
to
On Nov 25, 3:31 pm, Paul Rubin <http://phr...@NOSPAM.invalid>
wrote: ...

> If you know what the U in CUP stands for, that might complete the picture.

CUP = Cambridge University Press

but that does not complete the picture.

Förster vom Silberwald

unread,
Nov 29, 2007, 8:43:59 AM11/29/07
to


Hello: what do you mean by "accurate"? I thought a fft will always
give the same numerical result free from the method. I mean you can do
matrix-matrix multiplication by different methods but will just get
the same result, isn't it?

btw: what do C_scientific_programmer_people mean when they raise the
case against Fortran 90. I often wonder do they speak about simple
array calculations or do they mean at the same time all the other
stuff: experimenting, input, output, etc.

At the moment I have to deal with Fortran 90 programming project.
Still missing my Bigloo Scheme compiler.

When using C for data evaluation and want to go just beyond array
calculations how do people approach it: structures, pointers, and
linked lists? Do they always start from scratch?

I guess C++ has some nicely availabe libraries for such kind of
things. But what does C offer in this respect?

thanks for calrification

0 new messages