[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The future of CSP? Fault tolerant implementations?


I see numerous opportunities.

We do not need clever programmers anymore.
As long as the average result of a process once in a while is
acceptable, the overall process continues.

Programs evolve into living beings. Artificial Intelligence becomes
more and more important.

We have to start hospitals for frustrated processes, and overworked
computer systems. Applications will be organized as companies,
or countries: political systems will be installed...

The world of computing at once becomes much more interesting...

I forsee a revolution!

I think it can be a good term project for your course.
Maybe you should also involve some psychology students,.
I expect they will turn out to be the better programmers.


"G. S. Stiles" <dyke.stiles@xxxxxxxxxxx> on 2001/09/05 06:06:54

Please respond to dyke.stiles@xxxxxxxxxxx

To:     java-threads@xxxxxxxxx
cc:      (bcc: Marcel Boosten/BST/MS/PHILIPS)
Subject:  Re: The future of CSP? Fault tolerant implementations?

Greetings -

I just started up my fault-tolerance course, and the quote below struck a
cord...replication being a foundation of tolerance...

>Your ideas are brillant. :-)
>The more threads, the better.
>The less nonsense like synchronisation, the better... :-)

>Your approach solves one of the major problems caused
>by synchronisation: deadlock. When there is no synchronisation,
>there is no deadlock. Excellent!

If we have large numbers of threads, unsynchronized, each with a substantial
number of operations, the number of possible interleavings is astronomical.
Some interleavings may be ok, some not.

Suppose we launch multiple copies of each thread, and assume each thread
can check its results for correctness. With enough copies, we should get at
least one thread that yields a correct result. Threads that yield incorrect
results swallow those results and continue on (maybe restarting with the
correct result).

If threads can't self-check, copies of the same thread could check against
each other.

In either case different threads (thread groups) do not slow each other down.

Probabilities seem important here.

Free-range threads?

Looks like a good term project for the course...


Dyke Stiles
Department of Electrical and Computer Engineering
Utah State University
4120 Old Main Hill
Logan UT 84322-4120
Voice: +1-435-797-2840                          FAX:   +1-435-797-3054
Work:                http://www.engineering.usu.edu/ece/research/rtpc/
Play:  http://www.engineering.usu.edu/ece/research/rtpc/utah/utah.html