Subject: Re: [vhdl-200x] RE: Posix Threads
From: Evan Lavelle (eml@riverside-machines.com)
Date: Wed Jun 11 2003 - 11:15:52 PDT
vhdl-200x@grfx.com wrote:
>>From: Steve Casselman <sc@vcc.com>
>>
>>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
Nice and easy. Now the p(osix)threads equivalent, using C:
pthread_t thread_id[4];
int errcode;
errcode = pthread_create(
&thread_id[0],
NULL,
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
}
}
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
This archive was generated by hypermail 2b28 : Wed Jun 11 2003 - 11:16:50 PDT