Subject: Re: [vhdl-200x] RE: Posix Threads
From: vhdl-200x@grfx.com
Date: Thu Jun 12 2003 - 00:48:59 PDT
> From: Evan Lavelle <eml@riverside-machines.com>
>
> vhdl-200x@grfx.com wrote:
> > (snipped)
>
> I think I probably didn't make my point clearly enough. What I was
> trying to say was:
>
> 1 For the simple case which is supported by V95, 'fork/join' is far
> more concise and expressive than any pthreads solution. This is what my
> code fragments were intended to show. There are clearly more complex
> cases which can't be handled by fork/join, but that wasn't my point.
>
OK, but my point was there is no reason to add fork/join if it only
handles a simple case.
> 2 If we were to provide a standard calling interface to C code, then
> pthreads would come for free anyway. It doesn't need any language support.
We were talking about threads that belong to the simulation kernel, not
threads created by the user controlled from the simulation kernel. As
Peter suggests they would be on a par with regular VHDL processes just
created dynamically. What you are suggesting is more like co-simulation
(not that I object to that).
> 3 If we were instead to provide a standard calling interface to C++,
> then we would get the standard C++ library, including the STL, for free,
> and this is far more useful, on a day to day basis, than pthreads. We'd
> also get pthreads, possibly with a bit of extra work, since it has C
> linkage. I'm sure there are complications here I haven't thought about,
> but they should be resolvable.
>
> Additionally:
>
> > Since pthreads is just an API it would leave the VHDL simulator vendors
> > free to implement efficient implementations, if they want to just use
> > the standard C pthreads library that would be an option. HDLs tend to
>
> A simulator vendor is the wrong person to provide a pthreads library -
> it needs to come from the OS vendor. Look up Drepper & Molnar's paper
> 'The Native Posix Thread Library for Linux' for some background
> (<people.redhat.com/drepper/nptl-design.pdf>).
>
> > have a much higher number of threads than C programs so OS based
> > mechanisms for mutexes and thread context switching tend to be too
> > inefficient (SystemC's problem).
>
> As an aside, SystemC doesn't specify how the scheduler is implemented.
> The reference OSCI implementation is a normal
> single-process/single-thread app; it doesn't use threads. Using threads
> for HDL processes would be bizarre; it would be far too expensive
> (particularly on Linux, where a thread is actually a process). If you
> have the OSCI sources, you can find the evaluate/update code in the
> 'crunch' routine in sc_simcontext.cpp.
The last person I talked to about this said they were using "quickthreads"
(http://www.cs.washington.edu/research/compiler/papers.d/quickthreads.html,
http://sources.redhat.com/ml/cygwin/1999-12/msg00390.html).
All HDLs are just multi-threaded programing languages. Verilog and VHDL
are constructed to avoid placing data on the processor stack so that they
can switch threads (processes) without having the processor change context.
C++ compilers are not designed to do that, so moving control from one C++
model to another often requires a context save and restore to maintain the
stack for each model - you can write C++ that doesn't need to do that but
it's going to be awkward.
Kev.
> Evan
>
This archive was generated by hypermail 2b28 : Thu Jun 12 2003 - 00:52:18 PDT