Re: [vhdl-200x] RE: Posix Threads

Subject: Re: [vhdl-200x] RE: Posix Threads
Date: Wed Jun 11 2003 - 11:46:14 PDT

> From: Evan Lavelle <>
> wrote:
> >>From: Steve Casselman <>
> >>
> >>I like the synchronization aspects of Posix threads. "The Mutexes are simple
> >>lock primitives that can be used to control access to a shared resource and
> >>the condition variable which supplements mutexes by allowing threads to
> >>block and await a signal from another thread" (ripped off from somewhere on
> >>the net). Threads are used in Java and many other "latest greatest
> >>languages." We should make sure that we cover both Verilog style Fork/Join
> >>and Posix threads.
> >>
> >>Steve
> >
> >
> > I don't think you need both, the fork/join stuff is just a subset of the
> > p-threads functionality. A lot of the syntax in SystemVerilog (3.1) is
> > inconsistent and hard to extend - I'd try to avoid copying the style.
> >
> > Kev.
> The advantage of fork/join is that it's simple. Consider this:
> fork
> my_proc1(...);
> my_proc2(...);
> my_proc3(...);
> my_proc4(...);
> join

True, but change the "join" to "join_none" and then try to get a hndle on
"my_proc2" - it doesn't work so well.

> Nice and easy. Now the p(osix)threads equivalent, using C:
> pthread_t thread_id[4];
> int errcode;
> errcode = pthread_create(
> &thread_id[0],
> my_proc1,
> (void *)&args); // problem: how do we specify the args??
> if(errcode) {
> // do something
> }
> // repeat *all* the above for my_proc2, my_proc3, my_proc4
> // now join
> for(int i=0; i<4; i++) {
> if(pthread_join(thread_id[i], 0)) {
> // failed: do something
> }
> }

I would tend to use C++ and bury that in a process-group class :-)
> Ok, some of this verbosity is due to error handling which isn't present
> in the fork/join example, but it's a fact of life that you have to do
> error checking if you get the option to do it. If we were to have some
> sort of pthreads API, then I personally would be in favour of a
> fork/join shorthand for the simple default case.

> But are we (or is it just me?) getting the wrong end of the stick here?
> pthreads isn't part of any language specification; it's just a library,
> which requires OS support, and which happens to have a C API. The
> mutexes, condition variables, and semaphores don't need any support in
> VHDL - they're handled in the library and the OS. All that's needed is a
> VHDL API. But, if this is possible and it's going to be done, why stop
> (or start) at pthreads? Surely interfaces to both the C standard library
> and the STL would both be infinitely more useful than pthreads?
> Evan

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
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).

My main reason for citing pthreads (an exiting standard) is to make
hardware/software trade-off easier.


This archive was generated by hypermail 2b28 : Wed Jun 11 2003 - 11:48:49 PDT