Subject: Re: [vhdl-200x] RE: Posix Threads
From: Evan Lavelle (eml@riverside-machines.com)
Date: Thu Jun 12 2003 - 03:57:24 PDT
vhdl-200x@grfx.com wrote:
> 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).
Ok.. (and presumably you mean "controlled from the *OS* kernel" rather
than the 'simulator' kernel). This thread's subject and the Posix
references lead me to believe that people are actually interested in
real pthreads-style threads, rather than extensions to process-creation
semantics, which are two completely different things.
What about the people who wanted 'fork/join'? Are they happy with
dynamic processes? My guess is that they were looking for something else.
>>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.
This is getting OT, but I guess it does have some relevance. The OSCI
reference implementation does use the QuickThreads code for some
processes (thread processes). QuickThreads is a fast and lightweight
user-level thread abstraction, which is not kernel-aware. It provides no
synchronisation or scheduling, and basically just does context switching
by changing the stack pointer.
The term 'threads', as far as I'm aware, is normally used to refer Posix
threads, which are very different. The kernel has to know about threads,
for various reasons - threads can be placed on different processors in a
multi-processor system, the kernel has to assist with the
synchronisation primitives, threads must be signal-aware, and so on. In
this context, SystemC is single-threaded. When I run gdb on my SystemC
code I see one thread for the thread manager, one for SystemC, and all
my own explicitly-created threads.
Evan
This archive was generated by hypermail 2b28 : Thu Jun 12 2003 - 03:58:34 PDT