Front page | perl.perl5.porters |
Postings from November 1999
A new paradigm for threads
From:
bartels
Date:
November 22, 1999 10:50
Subject:
A new paradigm for threads
Message ID:
9911229432.AA943295998@mail.pixelmagic.com
I work as an electrical engineer, designing asics.
I wanted to develop something that would let me quickly model
hardware in perl. I was working on an ASIC design that had two
clock domains that passed data across a fifo, and it had
some pretty funky handshaking to cross that boundary. I wanted
something that would allow me to do a high level model to
prove to myself that the design would work or not.
What I came up with is currently on CPAN at:
http://www.cpan.org/modules/by-authors/id/G/GB/GBARTELS/
Hardware-Simulator-...
it is a rather simplistic module and is limited by the
fact that it doesn't use threads. Threads would give me
functionality I need within perl to create a full fledge
hardware simulation model within perl.
I've been waiting for perl threads to get ironed out,
become reliable, and become the default way to compile
the perl install tar.zip kit. But after talking with
some people within the perl community, I'm not sure
that is going to happen.
It seems that threads have a bad rap.
sharing global data among different threads is "bad",
"dangerous", and "difficult to design".
I would just like to say that, for a number of years now,
hardware engineers have reliably been designing code
that runs in parallel and shares global data.
what was needed was a paradigm/model for the designers to
think inside of.
perl threads have been approaching the task from a
software point of view, which is generally a single
task. The most I've seen would be forking off a process,
and then using blocking statements to keep separate
processes in sync. from a hardware point of view,
this is horrendously bad design, difficult to understand,
and even harder to maintain. its no wonder that
perl threads result in bad code.
the current model doesn't encourage good parallel design.
I would like to suggest that if perl threads used
a different paradigm, then many of the difficulties
that are associated with sharing global data among
many threads would go away.
it will not solve the problem that threaded perl
will run slower than unthreaded perl. but that
is a separate issue.
I have written a README file, that explains the basic
neccessary pieces of the puzzle. It describes the
language constructs that make it easy and reliable to
design parallel processes sharing global data.
It describes how it would be implemented internally,
and how it might look within perl.
If there is any interest in having threads be easy to
use and reliable to design with, let me know, and I will
forward you the README file.
Thanks,
Greg London
bartels@pixelmagic.com
-
A new paradigm for threads
by bartels