Threads on Windows and SGI
Jan Roelof de Pijper
Windows 98 and up and on a Silicon Graphics machine. The problem is that
I have to use a thread. I know how to create the thread I want on
Windows and I have also figured out how to create a (posix) thread on
the SGI. My question: Is it possible to have code that will work on both
platforms? I want to avoid using #ifdef ... #else ... #endif if
possible.
Anyone?
TIA,
Jan Roelof de Pijper
force...@zipworld.com.au
: I need to write a program that will compile, link and run both on MS
There is a port of pthreads to Win32. You could write your code with the
POSIX thread API and then include the distribution with your application.
In doing so please ensure you take into account any subtle platform nuances
between POSIX threads and the Win32 implementation and also any licensing
issues.
--
Cheers.
Alexander Terekhov
http://sources.redhat.com/pthreads-win32/conformance.html
> and also any licensing issues.
http://sources.redhat.com/cgi-bin/cvsweb.cgi/pthreads/COPYING?cvsroot=pthreads-win32
regards,
alexander.
Jan Roelof de Pijper
I'll try this.
Regards,
Jan Roelof
Jan Roelof de Pijper <jpi...@ipo.tue.nl> wrote:
:I need to write a program that will compile, link and run both on MS
Alexander Terekhov
Jan Roelof de Pijper wrote:
>
> Thanks very much!
>
> I'll try this.
You'll try WHAT? ;-) Well, I'm just a bit 'curious', so to speak.. ;-) ;-)
regards,
alexander.
John Taylor
<force...@zipworld.com.au> wrote in message
news:4FLJ8.2855$06.3...@nasal.pacific.net.au...
Another alternative is to define a platform independent interface for
threading. The application then becomes dependent on the new interface -
not a specific threading implementation. When you build the application its
just a matter of linking the appropriate platform implementation of the
interface.
This is probably alot more work than you have the time/energy available.
But it is a very clean and portable way of dealing with threads across
multiple platforms. There are various class libraries that provide this
kind of functionality. If you are interested, I can point you to an open
source (BSD licensing, aka "free as in beer") library that supports
threading under Windoze and POSIX.
--
John T. Taylor
email: jta...@shift-right.com
url: http://www.shift-right.com
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net
Patrick TJ McPhee
John Taylor <jta...@shift-right.com> wrote:
% Another alternative is to define a platform independent interface for
% threading.
But, posix already defines a platform-independent interface for
threading, Why not implement it (or use somrone else's implementation)
on the platform that doesn't provide it, and use the native interface
on all the others?
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Jim Rogers
> In article <3cfd2...@corp-goliath.newsgroups.com>,
> John Taylor <jta...@shift-right.com> wrote:
>
> % Another alternative is to define a platform independent interface for
> % threading.
>
> But, posix already defines a platform-independent interface for
> threading, Why not implement it (or use somrone else's implementation)
> on the platform that doesn't provide it, and use the native interface
> on all the others?
All this sounds like re-inventing the wheel. Would you provide
your own implementation of floating point arithmetic before writing
a program? I suspect most people would simply expect their compiler
to deal with the differences in floating point implementations on
various target platforms. The source code for an integer multiply
should look the same on all platforms.
Similarly, you should expect concurrent programming details to be
handled by your compiler, with your programming language supplying
an implementation-independent syntax. If you choose to use a
language that does not directly support concurrent programming
in its syntax you are using the wrong tool for the job.
Jim Rogers
Jan Roelof de Pijper
:
:Jan Roelof de Pijper wrote:
:>
:> Thanks very much!
:>
:> I'll try this.
:
:You'll try WHAT? ;-) Well, I'm just a bit 'curious', so to speak.. ;-) ;-)
:
Yes, I understand your curiosity: some of the replies reached the group
after my "I''l try this" follow-up, even though they are dated earlier
:). I meant the Win32 port of posix threads. I have also received a tip
about ZThreads through private mail: http://www.cse.buffalo.edu/~crahen
Thanks again for the responses.
Jan Roelof
:regards,
John Taylor
> But, posix already defines a platform-independent interface for
> threading, Why not implement it (or use somrone else's implementation)
> on the platform that doesn't provide it, and use the native interface
> on all the others?
I agree. Having a pthreads implementation for all of your target platforms
would do exactly what I was proposing in my previous post. Now, what do you
do if there is not pthread implementation (or one you can use because of
licensing, costs, etc.) for all of your target platforms? At this point you
will have to roll your own solution, even if it is just writing your own
implementation of pthreads for platform XYZ. This is were I start to have
some issues (my intent here is list my *personal* reasons for not
standardizing on pthreads - *not* to bash pthreads!).
1. POSIX defines a standard for pthreads, but allows to much latitude in the
implementation. In my experience no two implementations of pthreads have
been the same. These differences usually manifest themselves in your
application code as #ifdef..#else constructs, something the original poster
wanted to avoid. Worst case is that the differences are fatal to your
application. For example, last year I worked on a project that tried to use
Cygwin's pthread implementation. The application required 'task local
storage', but the pthread_setspecific() and pthread_getspecific() routines
where not implemented in Cygwin's pthreads.
2. Pthreads is a C interface. If a C++ interface is required, then you have
write wrapper classes anyway.
3. Pthreads is not the right interface. This includes things like pthreads
is too heavy, too light, or just does not provide functionality X. For
example coming from the embedded world, one of our projects required that we
preallocate all threads - including the memory for their stacks and
task-control-blocks. POSIX does define a pthread_attr_setstacksize() and
pthread_attr_setstackaddr(), but no operation to provide the memory for the
task control block.
Alexander Terekhov
Jan Roelof de Pijper wrote:
> :). I meant the Win32 port of posix threads. I have also received a tip
> about ZThreads through private mail: http://www.cse.buffalo.edu/~crahen
To me, Eric's stuff is sort-of Java-threading ('brain-dead' thing, BTW)
but in C++. Well, I don't really want to go into details, but consider
(yes, I know that Eric also provides sort-of 'condvars' [*on top* of
his 'monitors'...oh, my,...even with 'ThreadImpl::yield()-loops', gee],
but still...):
http://www.cse.Buffalo.EDU/~crahen/projects/zthread/porting.html#monitor
(AFAICT very, very Java-like thing; sort-of 'thread-specific', though ;-))
Now, click here ('amazing', but it's indeed the SUN's site):
http://developer.java.sun.com/developer/Books/performance2/chap4.pdf
(they don't quite get POSIX condvars *performance* driven RATIONALE/
semantics, though [AFAICT])
"....
Monitors, at their most general, are classes that control threads'
access to resources. Java synchronization is based on the variety
of monitors that were developed in the early 1970s by Per Brinch-
Hansen and C. A. R. Hoare, but Java synchronization is not as well
developed as Brinch-Hansen and Hoare monitors are.
...."
Note that *POSIX Threads* condvars (monitor = class[ mutex + n * condvar];
n >=1) ARE EVEN MORE 'well developed' than Brinch-Hansen and Hoare monitors.
Heck, check out also this:
"....
Despite Java's goal of reliability and catching as many errors
at compile time as possible, it provides nowhere near the same
level of support for writing reliable concurrent programs that
monitors provide.
This led Brinch-Hansen to express a great disappointment with
Java's synchronization.
He writes:
Java's most serious mistake was the decision to use the
sequential part of the language to implement the run-time
support for the parallel features. In 1975, Concurrent Pascal
demonstrated that platform-independent parallel programs (even
small operating systems) can be written as a secure programming
language with monitors. It is astounding to me that Java's
insecure parallelism is taken seriously by the programming
language community a quarter of a century after the invention
of monitors and Concurrent Pascal. It has no merit.***
...."
regards,
alexander.
[***] Brinch-Hansen, Per, "Java's Insecure Parallelism",
ACM SIGPLAN Notices, 34(4) April 1999.
"The author examines the synchronization features
of Java and finds that they are insecure variants
of his earliest ideas in parallel programming
published in 1972-73. The claim that Java supports
monitors is shown to be false. The author concludes
that Java ignores the last twenty-five years of
research in parallel programming languages."
Claus Aßmann
> This is probably alot more work than you have the time/energy available.
> But it is a very clean and portable way of dealing with threads across
> multiple platforms. There are various class libraries that provide this
> kind of functionality. If you are interested, I can point you to an open
> source (BSD licensing, aka "free as in beer") library that supports
> threading under Windoze and POSIX.
If the library is also for C, please post a link.
Thanks.
--
If you feel the urgent wish to send me a courtesy copy of a Usenet
posting, then make sure it's recognizable as such!
The FAQ: http://www.sendmail.org/faq/ Before you ask.
Alexander Terekhov
John Taylor wrote:
[...]
> If you are interested, I can point you to an open
> source (BSD licensing, aka "free as in beer") library that supports
> threading under Windoze and POSIX.
I'm interested, please point me to that OSS 'in-beer'-like thing.
regards,
alexander.