Discussion:
perl multithreading
(too old to reply)
SPX2
2007-05-26 09:00:40 UTC
Permalink
hi,im new to multithreading altough ive read some papers on it...and
tried to made some programs
in perl using threads.
what would you recommend using with perl multithreading on windows.
what would you recommend reading on a broader spectrum about
multithreading ?
what applications should i build to learn more about multithreading ?
what are the common applications that require in particular use of
multithreading ?(with
specific examples if possible)
where could i learn/read more about multithreading in perl?
are there any opensource projects in perl using multithreading ?
i know i ask many questions,thats because i want to learn
thank you
Joe Seigh
2007-05-26 11:00:37 UTC
Permalink
Post by SPX2
hi,im new to multithreading altough ive read some papers on it...and
tried to made some programs
in perl using threads.
what would you recommend using with perl multithreading on windows.
what would you recommend reading on a broader spectrum about
multithreading ?
what applications should i build to learn more about multithreading ?
what are the common applications that require in particular use of
multithreading ?(with
specific examples if possible)
where could i learn/read more about multithreading in perl?
are there any opensource projects in perl using multithreading ?
i know i ask many questions,thats because i want to learn
thank you
You'd be better off learning threading with a language that had
threading built in properly from the start, e.g. Java.

Perl, Ruby, Python, etc were orginally designed as single threaded
and threading added in after the fact when it was too late to do
clean and proper threading. A lot of BGL (big giant lock) and a
bit of "do you feel lucky".
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
SPX2
2007-05-26 11:09:27 UTC
Permalink
Post by Joe Seigh
Post by SPX2
hi,im new to multithreading altough ive read some papers on it...and
tried to made some programs
in perl using threads.
what would you recommend using with perl multithreading on windows.
what would you recommend reading on a broader spectrum about
multithreading ?
what applications should i build to learn more about multithreading ?
what are the common applications that require in particular use of
multithreading ?(with
specific examples if possible)
where could i learn/read more about multithreading in perl?
are there any opensource projects in perl using multithreading ?
i know i ask many questions,thats because i want to learn
thank you
You'd be better off learning threading with a language that had
threading built in properly from the start, e.g. Java.
Perl, Ruby, Python, etc were orginally designed as single threaded
and threading added in after the fact when it was too late to do
clean and proper threading. A lot of BGL (big giant lock) and a
bit of "do you feel lucky".
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
ok thanks, im thinking of learning java or erlang but,the othe
questions
still remain
s***@gmail.com
2007-05-26 23:18:11 UTC
Permalink
On May 26, 1:09 pm, SPX2 <***@gmail.com> wrote:
...
Post by SPX2
ok thanks, im thinking of learning java or erlang but,the othe
questions
still remain
If you feel more comfortable in Perl, just CPAN the "threads" and the
"threads::shared" packages and you can use proper multi-threading in
Perl.

You include

use threads;
use threads::shared;

in this order and go ahead. Before that you can consult perldoc and do
some googling as well.

Best Regards,
Szabolcs
s***@gmail.com
2007-05-27 15:29:20 UTC
Permalink
Post by Joe Seigh
You'd be better off learning threading with a language that had
threading built in properly from the start, e.g. Java.
I wonder what makes you think that threading would be built in more
properly in Java (from Java 1.5) than in Perl (from Perl 5.8).

In fact, as far as the language itself is concerned, I cannot see too
many language means built into Java for multi-threading support
either. All it has is some primitive form of Critical Region support
(see the synchronized block) and some built-in primitives for hand
made scheduling of the threads (see wait/notify/notifyAll calls). That
much is supported by any concurrency libraries, such as pthread or
Perl Thread-libraries. Unfortunately, the Java language means are
comparable to libraries, since the language does not support the
Critical Region properly.

Apart from that, Java supports the unstructured forking-like
threading. It is available in the pthread libraries and in the Perl
libraries as well.

However, even those primitive language means that were initially built
in Java are now discouraged by the Java concurrency-interest expert
group, as you know, in favour of java.util.concurrent.locks library
use. A comparable library is available for the Perl programmer as well
(see CPAN "threads::shared") and, consequently, multi-threading can be
used in Perl just as in Java.

With respect to multi-threading at least the two language platforms
are not so much different. Consequently, if some problem is easier to
deal with in Perl, Perl should be used rather than Java even if
multi-threading is to be applied.

After all, multi-threading patterns are language independent, aren't
they? At least it is the case, as far as we have to apply libraries of
similiar capabilities and until some language supports multi-threading
properly at the language level.

Best Regards,
Szabolcs
Joe Seigh
2007-05-28 11:59:32 UTC
Permalink
Post by s***@gmail.com
Post by Joe Seigh
You'd be better off learning threading with a language that had
threading built in properly from the start, e.g. Java.
I wonder what makes you think that threading would be built in more
properly in Java (from Java 1.5) than in Perl (from Perl 5.8).
[...]

If you've figured a way to make non multi-threaded programs multi-threaded
as good as programs that were designed to be multi-threaded from the start,
I wouldn't waste any time here. Form a company. Intel or somebody would
buy your company just like that. You'd be an instant millionaire.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Chris Thomasson
2007-05-29 07:41:26 UTC
Permalink
Post by Joe Seigh
Post by s***@gmail.com
Post by Joe Seigh
You'd be better off learning threading with a language that had
threading built in properly from the start, e.g. Java.
I wonder what makes you think that threading would be built in more
properly in Java (from Java 1.5) than in Perl (from Perl 5.8).
[...]
If you've figured a way to make non multi-threaded programs multi-threaded
as good as programs that were designed to be multi-threaded from the start,
I wouldn't waste any time here. Form a company. Intel or somebody would
buy your company just like that. You'd be an instant millionaire.
I can do that with a specific entity. Well, what how useful do you think
this is to the programming community in general:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/eb87f9cb2cb62d84


imho, the ability to transform a single-threaded on-thread-stack allocator
into a scaleable distributed lock-free multi-thread allocator is attractive
indeed...

?
SPX2
2007-05-29 09:23:50 UTC
Permalink
Post by Chris Thomasson
Post by Joe Seigh
Post by s***@gmail.com
Post by Joe Seigh
You'd be better off learning threading with a language that had
threading built in properly from the start, e.g. Java.
I wonder what makes you think that threading would be built in more
properly in Java (from Java 1.5) than in Perl (from Perl 5.8).
[...]
If you've figured a way to make non multi-threaded programs multi-threaded
as good as programs that were designed to be multi-threaded from the start,
I wouldn't waste any time here. Form a company. Intel or somebody would
buy your company just like that. You'd be an instant millionaire.
I can do that with a specific entity. Well, what how useful do you think
http://groups.google.com/group/comp.programming.threads/browse_frm/th...
imho, the ability to transform a single-threaded on-thread-stack allocator
into a scaleable distributed lock-free multi-thread allocator is attractive
indeed...
?- Hide quoted text -
- Show quoted text -
let us not turn this into a flame war,lets keep it constructive
discussion,thanks.
please if you have more suggestions on projects to make to use
threads in a proper manner,or better yet projects that need threads so
that they
can be built,or another exprimation ,the best of the three:
"projects that require threads in a natural way", i am looking forward
to seeing
those suggestions.
thank you
s***@gmail.com
2007-05-29 10:46:32 UTC
Permalink
Post by SPX2
please if you have more suggestions on projects to make to use
threads in a proper manner,or better yet projects that need threads so
that they
"projects that require threads in a natural way", i am looking forward
to seeing
those suggestions.
It looks like your question is not Perl specific despite the title of
the thread. If you are interested how you can use threads in Perl
technically then my previous comment applies. It is not different from
pthread library of Java at all as far as multi-threading is concerned.

Here are some pointers that my help on the technical side:

Perl Threads
http://migo.sixbit.org/papers/Perl_Threads/slide-index.html

perlthrtut - tutorial on threads in Perl
http://webmaster.iu.edu/perl56/pod/perlthrtut.html

Threading patterns are language independent until some language
supports threading at the language level.

Basically you can use multiple threads if you can identify activities
in your program that are independent from each other or need only
moderate interaction. One of those situations is the producer-consumer
relationship where the work of the producer and the work of the
consumer can proceed at the same time on disjoint items and the speed
difference can be smoothed by a bounded buffer between the producer
and the consumer.

One other case is where the problem space can be partitioned into
independent work packages and the packages can be distributed among a
set of worker threads.

All depends on the application. To estimate whether a particular
application can allow multi-threading in a natural way, as you have
put it, you need the experience and the different mind set from
sequential programming.

We say that multi-threading requires different thinking. Programmers
are usually infected with the sequential thinking even if it is not
necessary. The other point where programmers used to sequential
programming are often fail is that they still think in the background
that the "once true, always true" principle is still valid with shared
variables.

Best Regards,
Szabolcs
SPX2
2007-05-29 11:26:40 UTC
Permalink
Post by s***@gmail.com
Post by SPX2
please if you have more suggestions on projects to make to use
threads in a proper manner,or better yet projects that need threads so
that they
"projects that require threads in a natural way", i am looking forward
to seeing
those suggestions.
It looks like your question is not Perl specific despite the title of
the thread. If you are interested how you can use threads in Perl
technically then my previous comment applies. It is not different from
pthread library of Java at all as far as multi-threading is concerned.
Perl Threadshttp://migo.sixbit.org/papers/Perl_Threads/slide-index.html
perlthrtut - tutorial on threads in Perlhttp://webmaster.iu.edu/perl56/pod/perlthrtut.html
Threading patterns are language independent until some language
supports threading at the language level.
Basically you can use multiple threads if you can identify activities
in your program that are independent from each other or need only
moderate interaction. One of those situations is the producer-consumer
relationship where the work of the producer and the work of the
consumer can proceed at the same time on disjoint items and the speed
difference can be smoothed by a bounded buffer between the producer
and the consumer.
One other case is where the problem space can be partitioned into
independent work packages and the packages can be distributed among a
set of worker threads.
All depends on the application. To estimate whether a particular
application can allow multi-threading in a natural way, as you have
put it, you need the experience and the different mind set from
sequential programming.
We say that multi-threading requires different thinking. Programmers
are usually infected with the sequential thinking even if it is not
necessary. The other point where programmers used to sequential
programming are often fail is that they still think in the background
that the "once true, always true" principle is still valid with shared
variables.
Best Regards,
Szabolcs
well actually reading Tanenbaum's book on moder OS's he
gives two examples for multithreading(wich may or may not appear
as trivial to you but they are importnat to a beginner),
he says a web server and a text editor.
my question wasnt "if i want to make this application how can i figure
if it needs or not threads?".
my question was "what are some applications that require threads in
a natural way".
s***@gmail.com
2007-05-29 21:42:43 UTC
Permalink
Post by SPX2
well actually reading Tanenbaum's book on moder OS's he
gives two examples for multithreading(wich may or may not appear
as trivial to you but they are importnat to a beginner),
he says a web server and a text editor.
Do you think that a text editor is necessarily multi-threaded just
because it is an example in some books? Most applications can be
implemented either by sequential or by multi-threaded code. The author
of the book used it as an example, if it is there. I do not remember
that he would give such example in that book although it was long ago
I have consulted that book.

You can go ahead and pick up one of your programs made in Perl and
find some parts in them that can make use of parallel execution and
make it multi-threaded. If you want to learn, you should go ahead.
Post by SPX2
my question wasnt "if i want to make this application how can i figure
if it needs or not threads?".
my question was "what are some applications that require threads in
a natural way".
Right. Now I see that you do not really want to know what are the
circumstances when you can apply parallel programs in a natural way to
solve your programming task---rather you just want to know some very
examples. Fine. That is more simple than designing the parallel
application. Then here you find some applications:

operating systems
embedded systems
process control systems
data collectors
POS terminals
servers of various kinds
networks
etc.

Any application that interacts with the environment may be implemented
with help of threads in a natural way. I could tell you the reason why
too but you are not interested. On the other hand this list of
examples does not tell you too much since most applications can be
implemented by a single sequential program as well as by a parallel
one. Even an operating system can be a basically sequential program,
just look at the old MS-DOS. It is up to a designer what design
decisions she or he takes.

Most problems are inherently parallel, however, as your Java Joe-ker
would put---when you get a single processor with a sequential
language, you make sequential programs.

Best Regards,
Syabolcs
SPX2
2007-05-29 09:24:37 UTC
Permalink
Post by Chris Thomasson
Post by Joe Seigh
Post by s***@gmail.com
Post by Joe Seigh
You'd be better off learning threading with a language that had
threading built in properly from the start, e.g. Java.
I wonder what makes you think that threading would be built in more
properly in Java (from Java 1.5) than in Perl (from Perl 5.8).
[...]
If you've figured a way to make non multi-threaded programs multi-threaded
as good as programs that were designed to be multi-threaded from the start,
I wouldn't waste any time here. Form a company. Intel or somebody would
buy your company just like that. You'd be an instant millionaire.
I can do that with a specific entity. Well, what how useful do you think
http://groups.google.com/group/comp.programming.threads/browse_frm/th...
imho, the ability to transform a single-threaded on-thread-stack allocator
into a scaleable distributed lock-free multi-thread allocator is attractive
indeed...
?- Hide quoted text -
- Show quoted text -
i would like to also take into consideration the
following post on slashdot wich i found enlightening as well
http://developers.slashdot.org/article.pl?sid=07/05/29/0058246
Joe Seigh
2007-05-29 10:32:12 UTC
Permalink
Post by SPX2
Post by Chris Thomasson
Post by Joe Seigh
[...]
If you've figured a way to make non multi-threaded programs multi-threaded
as good as programs that were designed to be multi-threaded from the start,
I wouldn't waste any time here. Form a company. Intel or somebody would
buy your company just like that. You'd be an instant millionaire.
I can do that with a specific entity. Well, what how useful do you think
http://groups.google.com/group/comp.programming.threads/browse_frm/th...
imho, the ability to transform a single-threaded on-thread-stack allocator
into a scaleable distributed lock-free multi-thread allocator is attractive
indeed...
[...]
Post by SPX2
i would like to also take into consideration the
following post on slashdot wich i found enlightening as well
http://developers.slashdot.org/article.pl?sid=07/05/29/0058246
That's Intel PR trying to get everyone to do more "parallel" programming
because applications won't get faster automatically like they used to.

A large part of the problem, is that multi-threaded programming isn't very
high up on your typicall PHB's agenda if it's there at all. Plus everyone
knows how difficult multi-threaded programming is, so being mediocre or
even particularly lame at multi-threaded programming has never hurt anyone's
career path as long as they have one of the hot skills.

Heck, you've got weenies who think the lame multi-threaded implementations of
Perl, Ruby, et al are good enough.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
David Hopwood
2007-05-29 23:27:06 UTC
Permalink
Post by Joe Seigh
A large part of the problem, is that multi-threaded programming isn't very
high up on your typical PHB's agenda if it's there at all.
Why would it need to be? Whether to use multithreading is a technical
decision, not a management one.
--
David Hopwood <***@industrial-designers.co.uk>
SPX2
2007-05-31 09:48:08 UTC
Permalink
ok thanks for the list of applications you have provided that
need mt.
now i want to ask,what articles/books on mt should i read in your
oppinion?
are do threads in perl POSIX -compliant ?
how much standards are there for threads,theres this POSIX of wich i
know
Butenhof has a book,and are there others ?
what is the difference between user-level and kernel-level threads ? i
have read
about it in here http://linas.org/linux/threads-faq.html#ThreadsDefinition
and in
tanenbaum modern operating systems as well but i did not understand
the concept.
what can i do to be prepared to take a job in multi-threading?
i suppose and i want to solve problems on mt but i dont know where to
start/read...
i also know that i should read code on it,what do you recommend
reading ?
thank you
Szabolcs Ferenczi
2007-05-31 22:14:34 UTC
Permalink
Post by SPX2
ok thanks for the list of applications you have provided that
need mt.
You are welcome.
Post by SPX2
now i want to ask,what articles/books on mt should i read in your
oppinion?
Which articles/books you should read depends on your character. We are
all different so it is a different article/book that rings the bell.---
Although it was not termed multi-threading at that time, I have read a
lot of works of Per Brinch Hansen, C.A.R. Hoare and E.D.W. Dijkstra,
which gives you a very firm background just like the Tanenbaum book.
You can find their classic papers in most collections but here are
some pointers too:

http://brinch-hansen.net/
http://www.cs.utexas.edu/users/EWD/

The book P. Brinch Hansen, Architecture of Concurrent Programs,
Prentice Hall, Englewood. Cliffs,. N.J.,. 1977. is still a valuable
reading for anyone seriously interested in MT and shared objects.

If you want something more close to the technical side of multi-
threading, this is a classic book available on line:

PThreads Primer
A Guide to Multithreaded Programming
Bil Lewis
Daniel J. Berg
SunSoft Press
A Prentice Hall Title
1996 Sun Microsystems, Inc.
http://www.cs.umu.se/kurser/TDBC64/VT03/pthreads/pthread-primer.pdf

But this only gives you the tool and it does not really help you on
the principles.

For Perl multi-threading I have provided some references already but
this is one more:

Going Up?
A Multi-Threaded Elevator Simulator in Perl
by Sam Tregar
September 04, 2002
http://www.perl.com/pub/a/2002/09/04/threads.html

If you are thinking in Java, you can check:

Concurrent Programming In Java
© 1996 Doug Lea
http://gee.cs.oswego.edu/dl/cpj

Concurrent Programming Using Java
http://www.mcs.drexel.edu/~shartley/ConcProgJava/

Java Concurrency in Practice. Addison-Wesley, 2006. With Tim
Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea.
http://www.briangoetz.com/pubs.html

Others will hopefully suggest you more literature.
Post by SPX2
are do threads in perl POSIX -compliant ?
No, not 100% as far as I know. But it does not matter if you want to
do multi-threading in Perl. If you are interested in multi-threading
and you do not want to make use of the special details, any threading
scheme will do. You can make use of the basic threaded patterns in any
scheme.
Post by SPX2
how much standards are there for threads,theres this POSIX of wich i
know
I do not know how many standards are there. Perhaps someone else can
help you in that. Are you going to do multi-threading or are you
making a survey about the standards?
Post by SPX2
Butenhof has a book,and are there others ?
Yes, see above. But there are even more.
Post by SPX2
what is the difference between user-level and kernel-level threads ? i
have read
about it in here http://linas.org/linux/threads-faq.html#ThreadsDefinition
and in
tanenbaum modern operating systems as well but i did not understand
the concept.
I am afraid you should be familiar with the basics first.
Post by SPX2
what can i do to be prepared to take a job in multi-threading?
Practice a lot.
Post by SPX2
i suppose and i want to solve problems on mt but i dont know where to
start/read...
See some references above and use Google. But first of all, start
practicing.
Post by SPX2
i also know that i should read code on it,what do you recommend
reading ?
For Perl multi-threading see:

http://search.cpan.org/~jdhedden/threads-1.61/threads.pm
http://search.cpan.org/~nwclark/perl-5.8.8/pod/perlthrtut.pod
http://www.perl.com/pub/a/2002/09/04/threads.html
Post by SPX2
thank you
You just ask a lot just like a professional philosopher. You seem to
keep asking even when you got the answer. In philosophy it is a virtue
but in practice it is not really one.

Best Regards,
Szabolcs
SPX2
2007-06-02 08:00:01 UTC
Permalink
Post by Szabolcs Ferenczi
Post by SPX2
ok thanks for the list of applications you have provided that
need mt.
You are welcome.
Post by SPX2
now i want to ask,what articles/books on mt should i read in your
oppinion?
Which articles/books you should read depends on your character. We are
all different so it is a different article/book that rings the bell.---
Although it was not termed multi-threading at that time, I have read a
lot of works of Per Brinch Hansen, C.A.R. Hoare and E.D.W. Dijkstra,
which gives you a very firm background just like the Tanenbaum book.
You can find their classic papers in most collections but here are
http://brinch-hansen.net/http://www.cs.utexas.edu/users/EWD/
The book P. Brinch Hansen, Architecture of Concurrent Programs,
Prentice Hall, Englewood. Cliffs,. N.J.,. 1977. is still a valuable
reading for anyone seriously interested in MT and shared objects.
If you want something more close to the technical side of multi-
PThreads Primer
A Guide to Multithreaded Programming
Bil Lewis
Daniel J. Berg
SunSoft Press
A Prentice Hall Title
1996 Sun Microsystems, Inc.http://www.cs.umu.se/kurser/TDBC64/VT03/pthreads/pthread-primer.pdf
But this only gives you the tool and it does not really help you on
the principles.
For Perl multi-threading I have provided some references already but
Going Up?
A Multi-Threaded Elevator Simulator in Perl
by Sam Tregar
September 04, 2002http://www.perl.com/pub/a/2002/09/04/threads.html
Concurrent Programming In Java
� 1996 Doug Leahttp://gee.cs.oswego.edu/dl/cpj
Concurrent Programming Using Javahttp://www.mcs.drexel.edu/~shartley/ConcProgJava/
Java Concurrency in Practice. Addison-Wesley, 2006. With Tim
Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea.http://www.briangoetz.com/pubs.html
Others will hopefully suggest you more literature.
Post by SPX2
are do threads in perl POSIX -compliant ?
No, not 100% as far as I know. But it does not matter if you want to
do multi-threading in Perl. If you are interested in multi-threading
and you do not want to make use of the special details, any threading
scheme will do. You can make use of the basic threaded patterns in any
scheme.
Post by SPX2
how much standards are there for threads,theres this POSIX of wich i
know
I do not know how many standards are there. Perhaps someone else can
help you in that. Are you going to do multi-threading or are you
making a survey about the standards?
Post by SPX2
Butenhof has a book,and are there others ?
Yes, see above. But there are even more.
Post by SPX2
what is the difference between user-level and kernel-level threads ? i
have read
about it in herehttp://linas.org/linux/threads-faq.html#ThreadsDefinition
and in
tanenbaum modern operating systems as well but i did not understand
the concept.
I am afraid you should be familiar with the basics first.
Post by SPX2
what can i do to be prepared to take a job in multi-threading?
Practice a lot.
Post by SPX2
i suppose and i want to solve problems on mt but i dont know where to
start/read...
See some references above and use Google. But first of all, start
practicing.
Post by SPX2
i also know that i should read code on it,what do you recommend
reading ?
http://search.cpan.org/~jdhedden/threads-1.61/threads.pmhttp://search.cpan.org/~nwclark/perl-5.8.8/pod/perlthrtut.podhttp://www.perl.com/pub/a/2002/09/04/threads.html
Post by SPX2
thank you
You just ask a lot just like a professional philosopher. You seem to
keep asking even when you got the answer. In philosophy it is a virtue
but in practice it is not really one.
Best Regards,
Szabolcs
thanks for the links but before i started this thread ive already read
all of those
before starting this thread.
ive come to the conclusion that i dont yet grasp the mt concepts in
theory and
thats why i cant apply them in practice.
im also aware and think(correct me if im wrong) that any serious
language be it
script or compiled-linked language has this concepts implemented
so i started learning from tanenbaum's book and when i finish i'll
apply all of
them in perl
Szabolcs Ferenczi
2007-06-02 12:20:19 UTC
Permalink
Post by SPX2
thanks for the links but before i started this thread ive already read
all of those
before starting this thread.
That is very interesting. I did not read all of them myself and I
doubt if there is anyone out there who could say that he or she read
them all.
Post by SPX2
ive come to the conclusion that i dont yet grasp the mt concepts in
theory and
thats why i cant apply them in practice.
I do not know how much of the theory you have grasped already since
you just keep asking and not really say anything about how much you
have learnt. Sometimes you even provide false information.

I would summarize the most important principle for you by a quote from
Dijkstra:

`In normal sequential programming we have regarded an alternative
construct with all its guards false as a reason for abortion. An
equivalent rule for the implementation would be: postpone progress of
this computation as long as all the guards are false. In a
uniprogramming environment we have "once all false, always all false"
and this second rule would be as good as abortion. In a
multiprogramming environment it would mean for the daemon that as
suggestes on page EWD554 - 6, "an alternative construct, peceded
immediately by its "preceding predicate" will never be selected for
excecution in those machine states where its selection for excecution
would lead to abortion of that program".'

You can find it an some more arguments on p.199 in EWD 554 A personal
summary of the Gries-Owicki Theory :
Edsger W. Dijkstra, Selected Writings on Computing: A Personal
Perspective, Springer-Verlag, 1982. ISBN 0-387-90652-5.

See also p. EWD554 - 13 in http://www.cs.utexas.edu/users/EWD/ewd05xx/EWD554.PDF

Since the "once false, always false" does not hold for shared
variables, it can explain you why it is a mistake in multi-threading
environment for instance to check a queue from a thread and do
something else if it is empty.
Post by SPX2
im also aware and think(correct me if im wrong) that any serious
language be it
script or compiled-linked language has this concepts implemented
so i started learning from tanenbaum's book and when i finish i'll
apply all of
them in perl
If you ask me, my answer is that most of the modern programming
languages do not support multi-threading at the language level with
the proper language means. But I have pointed this out earlier to you.

You can use Perl for multi-threading as you can use any other
languages such as Java, C#, C++, C, etc. You do not have to complete
Tanenbaum's book for that since it is much more than multi-threading,
actually, it is about operating systems. In fact, multi-threading is
not concerned there directly. At least, I would say, reading that book
is not the best way to get into multi-threading.

If you aim at Perl, this earlier suggested reading should be enough
for you to start:

perlthrtut - tutorial on threads in Perl
http://search.cpan.org/~nwclark/perl-5.8.8/pod/perlthrtut.pod

It has enough examples to start with as well.

You have read it as you claim. Then you can go ahead and do some work
with the examples. That will be the best way to learn.

Best Regards,
Szabolcs
SPX2
2007-06-03 00:05:44 UTC
Permalink
Post by Szabolcs Ferenczi
Post by SPX2
thanks for the links but before i started this thread ive already read
all of those
before starting this thread.
That is very interesting. I did not read all of them myself and I
doubt if there is anyone out there who could say that he or she read
them all.
Post by SPX2
ive come to the conclusion that i dont yet grasp the mt concepts in
theory and
thats why i cant apply them in practice.
I do not know how much of the theory you have grasped already since
you just keep asking and not really say anything about how much you
have learnt. Sometimes you even provide false information.
I would summarize the most important principle for you by a quote from
`In normal sequential programming we have regarded an alternative
construct with all its guards false as a reason for abortion. An
equivalent rule for the implementation would be: postpone progress of
this computation as long as all the guards are false. In a
uniprogramming environment we have "once all false, always all false"
and this second rule would be as good as abortion. In a
multiprogramming environment it would mean for the daemon that as
suggestes on page EWD554 - 6, "an alternative construct, peceded
immediately by its "preceding predicate" will never be selected for
excecution in those machine states where its selection for excecution
would lead to abortion of that program".'
You can find it an some more arguments on p.199 in EWD 554 A personal
Edsger W. Dijkstra, Selected Writings on Computing: A Personal
Perspective, Springer-Verlag, 1982. ISBN 0-387-90652-5.
See also p. EWD554 - 13 inhttp://www.cs.utexas.edu/users/EWD/ewd05xx/EWD554.PDF
Since the "once false, always false" does not hold for shared
variables, it can explain you why it is a mistake in multi-threading
environment for instance to check a queue from a thread and do
something else if it is empty.
Post by SPX2
im also aware and think(correct me if im wrong) that any serious
language be it
script or compiled-linked language has this concepts implemented
so i started learning from tanenbaum's book and when i finish i'll
apply all of
them in perl
If you ask me, my answer is that most of the modern programming
languages do not support multi-threading at the language level with
the proper language means. But I have pointed this out earlier to you.
You can use Perl for multi-threading as you can use any other
languages such as Java, C#, C++, C, etc. You do not have to complete
Tanenbaum's book for that since it is much more than multi-threading,
actually, it is about operating systems. In fact, multi-threading is
not concerned there directly. At least, I would say, reading that book
is not the best way to get into multi-threading.
If you aim at Perl, this earlier suggested reading should be enough
perlthrtut - tutorial on threads in Perlhttp://search.cpan.org/~nwclark/perl-5.8.8/pod/perlthrtut.pod
It has enough examples to start with as well.
You have read it as you claim. Then you can go ahead and do some work
with the examples. That will be the best way to learn.
Best Regards,
Szabolcs
ok it seems i just made a first approach to dining philosophers
problem(i mean my first approach,
im aware many people from many places came up with much better
solutions)
http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/threads/diningphilosophers.pl
im thinking of also taking into consideration that the highest degree
of parallelisation in this
case could be 2 because there are only 5 philosophers so that a cycle
like this could work
{1,3} {2,4} {3,5} {4,1} and repeat it forever,every block {x,y} means
x is run in parallel with y and
this can be done as there are enough forks and {x,y} are so chosen in
the past sequence so
that no x and y share any forks.
for a general version i think one could select the biggest subsets of
the set of philosophers so
that no 2 philosophers from these biggest subsets share any fork at
all.
i guess this starts to relate somehow to ramsey theory.
Szabolcs Ferenczi
2007-06-03 12:32:21 UTC
Permalink
Post by SPX2
ok it seems i just made a first approach to dining philosophers
problem(i mean my first approach,
im aware many people from many places came up with much better
solutions)http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/thread...
You did not start with a simple problem, I must say.

My first remark is that your first solution has some logical flaw.
Namely, the problem says that the life of a philosopher alternates
between thinking and eating.

Philosopher n: (eat think)+

Your solution do not implement this but someting like thinking and
then attempting to eat and only eventually eat.

Philosopher n: (think+ eat)+

Next remark is that you demonstrate the typical mistake I have called
your attention to: You check the status of a shared variable (@forks)
and make decision on the instant status of it. Remember, the `once
false, always false' only applies to sequential programs but not to
multi-threaded ones.

Third remark: Your `are_forks_free' query should use locking as well.
But that is not enough because the existence of this query should be
elminated or it should be moved inside another operation, e.g.
`grab_forks'. Anyway it is always a better idea to abstract the shared
resource and the associated operations on it into a package.

package Forks;
my @forks:shared=(0,0,0,0,0,0);
sub fork_op_1 {
lock @forks;
<...>
}
sub fork_op_n {
lock @forks;
<...>
}
;

Try not to implement any query interface for the packages of shared
variable handling whenever possible.

Also I would suggest you to make unit tests for your packages. Even
better if you can use test first development method for them.

Collecting the shared resource and the handling procedures into a
package is a way to compensate for the lack proper language means. In
a proper language there should be some keyword to mark which is a
shared resource and then the complier should check whether that shared
resource is properly accessed inside a critical region.

E.g.:
shared (s: integer);
...
with (s) do s := 1; end

Fourth remark: Try to test your code before publishing it. Your
current solution contains dead code. Note that if you just replace
your `while(1)' with `foreach(1..LIFETIME)', your program would
eventually terminate.

Technical remark: If you want to see your trace messages while your
threads are progressing, you can insert a `$|++;' statement after each
`print' statement. Even better if you extract the prints into a trace
block and you care about the mutual exclusion of the threads as well.
Do not forget that the screen or standard output is a shared resource
too.

package Trace;
my $screen : shared;
sub put_line { lock $screen; print shift, "\n"; $|++; }
;
Post by SPX2
im thinking of also taking into consideration that the highest degree
of parallelisation in this
This problem is not about to demonstrate how you can exploit the
parallelism. It is rather a problem where some resource handling
issues arise such as deadlock and starvation. You should attempt to
give a solution where you can demonstrate that deadlock and starvation
do not apply.

Best Regards,
Szabolcs
SPX2
2007-06-04 12:16:50 UTC
Permalink
Post by Szabolcs Ferenczi
Post by SPX2
ok it seems i just made a first approach to dining philosophers
problem(i mean my first approach,
im aware many people from many places came up with much better
solutions)http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/thread...
You did not start with a simple problem, I must say.
My first remark is that your first solution has some logical flaw.
Namely, the problem says that the life of a philosopher alternates
between thinking and eating.
Philosopher n: (eat think)+
Your solution do not implement this but someting like thinking and
then attempting to eat and only eventually eat.
Philosopher n: (think+ eat)+
Next remark is that you demonstrate the typical mistake I have called
and make decision on the instant status of it. Remember, the `once
false, always false' only applies to sequential programs but not to
multi-threaded ones.
Third remark: Your `are_forks_free' query should use locking as well.
But that is not enough because the existence of this query should be
elminated or it should be moved inside another operation, e.g.
`grab_forks'. Anyway it is always a better idea to abstract the shared
resource and the associated operations on it into a package.
package Forks;
sub fork_op_1 {
<...>}
sub fork_op_n {
<...>}
;
Try not to implement any query interface for the packages of shared
variable handling whenever possible.
Also I would suggest you to make unit tests for your packages. Even
better if you can use test first development method for them.
Collecting the shared resource and the handling procedures into a
package is a way to compensate for the lack proper language means. In
a proper language there should be some keyword to mark which is a
shared resource and then the complier should check whether that shared
resource is properly accessed inside a critical region.
shared (s: integer);
...
with (s) do s := 1; end
Fourth remark: Try to test your code before publishing it. Your
current solution contains dead code. Note that if you just replace
your `while(1)' with `foreach(1..LIFETIME)', your program would
eventually terminate.
Technical remark: If you want to see your trace messages while your
threads are progressing, you can insert a `$|++;' statement after each
`print' statement. Even better if you extract the prints into a trace
block and you care about the mutual exclusion of the threads as well.
Do not forget that the screen or standard output is a shared resource
too.
package Trace;
my $screen : shared;
sub put_line { lock $screen; print shift, "\n"; $|++; }
;
Post by SPX2
im thinking of also taking into consideration that the highest degree
of parallelisation in this
This problem is not about to demonstrate how you can exploit the
parallelism. It is rather a problem where some resource handling
issues arise such as deadlock and starvation. You should attempt to
give a solution where you can demonstrate that deadlock and starvation
do not apply.
Best Regards,
Szabolcs
thank you very much for the heads up.
i agree with you that i misunderstood the problem in the sense that i
was
doing something like:

----------
are forks available ?
yes: eat , meditate
no : meditate
----------

while i should have done it like this

----------
are forks available ?
yes: eat , meditate
no : wait for forks,eat ,meditate
----------


i have kept the other branch of the if that shows
if a philosopher did not aquire forks so that it shows me if
i found a good or bad solution.
ive read also the solution presented by tanenbaum and he
has this array of semaphores wich are the forks at the same time,so
he seems to have double semantism for an entry in such an array
1)it is 0 if fork is in use and 1 if its not
2)its a semaphore with blocking capabilities

unfortunately i do not have yet a good grasp of Perl OOP so that i can
implement what you say about packages,altough i believe its for the
best.
(i tried today and failed miserably because what im reading on perl
oop is
just some chapter in a book i found interesting,but its not focusing
particularly
on oop,its a more borader book http://greenteapress.com/perl/perl.pdf
, when
i finish it i hope ill get some good book on oop)
i got that the simplest solution is a semaphore on the critical region
http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/threads/diningphilosophers_semaph.pl
also ive followed your advice and made a solution using locks
http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/threads/diningphilosophers_lock.pl
and got a solution and interesting(to me) i got something else also
a "solution" where only philosopher 1 gets to eat and meditate.
http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/threads/diningphilosophers_stuck.pl
(this is the weirdest thing because on linux it gets stuck on
philosopher 1 and doesnt let go
while on windows it gets on moving with other threads as well,i cant
explain this difference of behaviour
and i think that the logical one should be the one on linux because it
has a lock in the while and
no other thread gets tu use @forks)


about the locking of the screen ... i havent figgured out a better way
than this
http://perlmonks.org/?node_id=619092
ive started up a discussion there...i didnt know how to do it very
well.
some other question i have is the "for(1..LIFETIME)" - i think this
will be system-dependant
in time metric i mean...or am i wrong ?
Szabolcs Ferenczi
2007-06-04 18:55:08 UTC
Permalink
Post by SPX2
i have kept the other branch of the if that shows
if a philosopher did not aquire forks so that it shows me if
i found a good or bad solution.
It is the problem that you are still thinking in that inappropriate if
statement. At that point you are not supposed to use an if statement
at all. That is the typical mistake someone can commit when changing
from sequential programming to multi-threading. As I keep telling you,
in multi-threading environment is is not a safe strategy to make any
decision on the momentary status of some shared resource. The `once
false, always false' is not applicable.

At that point the philosopher shoud be delayed by some means until it
can grasp the two forks.
Post by SPX2
unfortunately i do not have yet a good grasp of Perl OOP so that i can
implement what you say about packages,altough i believe its for the
best.
Using packages in Perl is not yet OOP. A package in Perl is simply a
module that determines a limited a scope. You can use it as I have
shown above.
Post by SPX2
i got that the simplest solution is a semaphore on the critical region
http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/thread...
It is so simple that you have serialized it. Only one philosopher is
able to eat in your simple solution. The critical section includes all
the forks and extends from getting the forks, eating and putting the
forks down.---The size of the critical section should be kept at a
minimum size. You have applied a critical section in that example that
is larger than necessary.

Let me note that when you move with the size of the critical section
towards a minimum, you will arrive at somewhere near to the lock-free
area.
Post by SPX2
also ive followed your advice and made a solution using locks
http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/thread...
and got a solution and interesting(to me) i got something else also
a "solution" where only philosopher 1 gets to eat and meditate.
It is because you did not really followed the advice. I suggested you
to use a package for the forks as a shared resource to limit the
scope. You did not do that. Consequently, you did not get any warning
so far that you mistakenly accessed the `@forks' resource where you
were not intend to use it. In the if branch of the philosopher you
left a `lock @forks;' statement by accident, I suppose. If you
followed my advice, the Perl interpreter were shouting that it does
not know about `@forks' at that point. Here it means that you got a
larger critical section than what you wanted. The locks can be nested
in Perl and the outermost lock is effective.
Post by SPX2
http://perlhobby.googlecode.com/svn/trunk/scripturi_perl_teste/thread...
(this is the weirdest thing because on linux it gets stuck on
philosopher 1 and doesnt let go
while on windows it gets on moving with other threads as well,i cant
explain this difference of behaviour
and i think that the logical one should be the one on linux because it
has a lock in the while and
Here you have moved the locking out to the entire loop. It means that
the whole lifeline of the philosopher excludes the others except for a
very small window when the loop turns.
Post by SPX2
some other question i have is the "for(1..LIFETIME)" - i think this
will be system-dependant
in time metric i mean...or am i wrong ?
I meant that you could use a finite loop instead of the infinite one.

E.g.
use constant LIFETIME => 100;

It is `foreach(1..LIFETIME)' and not `for'. It is a shorthand for the
`for (my $i=1; $i <= LIFETIME; $i++)'.

Best Regards,
Szabolcs

Continue reading on narkive:
Loading...