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

Subject: Re: [vhdl-200x] RE: Posix Threads
From: Evan Lavelle (
Date: Wed Jun 11 2003 - 11:15:52 PDT 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.
> 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:


Nice and easy. Now the p(osix)threads equivalent, using C:

    pthread_t thread_id[4];
    int errcode;

    errcode = pthread_create(
       (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

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?


This archive was generated by hypermail 2b28 : Wed Jun 11 2003 - 11:16:50 PDT