Boost.Threads and Dinkum CoreX
Kiril Avdeiv
library for C++, namely Boost.Threads. Given that most of good libraries
at boost (BGL and regex come to mind) have the potential of being
incorporated into the next revision of ISO/IEC 14882, I thought that
sticking with Boost.Threads would be a fairly safe bet.
Recently, however, I found out that Dinkumware have prepared their own
version of a portable multithreading library for C++. Here is an excerpt
from their site:
<quoting>
The Dinkum CoreX multi-threading primitives can all be called from a C
program, but the library also includes a class-based interface better
suited to C++ programs. Naturally, the C and C++ interfaces synchronize
with each other, as well as with the multi-threading code in our
Standard C and C++ libraries. This library supports per-thread storage
of static data, with automatic initialization at thread creation. Or you
can synchronize access to shared global data. We've tested this library
on both Win32 and Posix systems, including Linux and Solaris, so it's
ready to run on most popular systems. The code is easily ported to any
multi-threading operating system with a thread model that resembles one
of these systems.
</quoting>
My question is -- does anybody know the following:
1. How compatible the two multithreading libraries are?
2. Which one currently targets more OS's?
3. Which one is more likely to serve as a prototype for inclusion into
the next revision of ISO/IEC 14882? The reason I ask this one is because
I know that both PJ Plauger and Peter are in the library working group
and therefore have influence on the final decision.
Many thanks in advance
Kiril
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Eric D Crahen
> This library supports per-thread storage
> of static data, with automatic initialization at thread creation. Or you
> can synchronize access to shared global data. We've tested this library
> on both Win32 and Posix systems, including Linux and Solaris, so it's
> ready to run on most popular systems. The code is easily ported to any
> multi-threading operating system
There is also library a called ZThreads that has these features as well.
> 3. Which one is more likely to serve as a prototype for inclusion into
> the next revision of ISO/IEC 14882? The reason I ask this one is because
> I know that both PJ Plauger and Peter are in the library working group
> and therefore have influence on the final decision.
I'm curious about how libraries are selected for this kind of
consideration. If possible, I would like to make some type of
contribution.
- Eric
http://www.cse.buffalo.edu/~crahen
Scott Robert Ladd
For true multiprocessing work on supercomputers and clusters, you can find
portable libraries like MPI (http://www.mpi-forum.org) and PVM
(http://www.epm.ornl.gov/pvm/pvm_home.html). I've used MPI quite
successfully on Beowulf clusters.
Some compilers (Intel, for instance) support the OpenMP
(http://www.openmp.org/) standard, which is a set of pragmas for
implementing portable threading in C, C++, and Fortran.
And then there is ZThread (http://zthread.sourceforge.net/news.html), a
library of C++ classes for threading.
What you chose depends on your intended design or platform.
--
Scott Robert Ladd
http://www.coyotegulch.com
No ads -- just info, algorithms, and very free code.
======================================= MODERATOR'S COMMENT:
This leaf of the conversation is no longer standards-related. No followups, please.
Alexander Terekhov
Kiril Avdeiv wrote:
[...Boost.Threads/mysterious Dinkum CoreX MT-stuff, class-based
included...]
> My question is -- does anybody know the following:
> 1. How compatible the two multithreading libraries are?
Don't know about CoreX-beast, but Boost.Threads is...
well, seriously "incomplete". So, knowing NOTHING about
CoreX, nevertheless I just hope that "compatibility" w.r.t.
Boost.Threads isn't on the issues list of Dinkumware folks.
Here is some feedback/comments on Boost.Threads available
on c.p.t newsgroup:
http://groups.google.com/groups?threadm=3CB14C2F.349AEF75%40web.de
> 2. Which one currently targets more OS's?
That's an easy one! ;-) POSIX threads[1] (ANSI/IEEE/...
extension to ANSI C) with whatever (if any) C++
add-ons/wrappers (sort-of "homegrown" C++ bindings)
you like/need/want (things like portable C++ exception
based thread-cancel and thread-exit, etc. -- pure
C++-specific (non-C) stuff/"issues" aside).
regards,
alexander.
[1]
http://www.opengroup.org/onlinepubs/007904975/basedefs/pthread.h.html
http://www.opengroup.org/onlinepubs/007904975/basedefs/sched.h.html
http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09
Alexander Terekhov
Eric D Crahen wrote:
>
> On Wed, 17 Apr 2002, Kiril Avdeiv wrote:
>
> > This library supports per-thread storage
> > of static data, with automatic initialization at thread creation. Or you
> > can synchronize access to shared global data. We've tested this library
> > on both Win32 and Posix systems, including Linux and Solaris, so it's
> > ready to run on most popular systems. The code is easily ported to any
> > multi-threading operating system
>
> There is also library a called ZThreads that has these features as well.
Sort-of "feedback/comments" from me-NOT-an-MT-expert (seriously)
including a couple of write-ups from Eric:
http://groups.google.com/groups?threadm=3CB5AC7A.9C1A79A8%40web.de
(I mean the entire sub-thread)
HTH.
regards,
alexander.
Pete Becker
>
> My question is -- does anybody know the following:
> 1. How compatible the two multithreading libraries are?
Our C++ interface is essentially Boost.Threads. We also provide a
pthread-like interface in C. Boost.Threads doesn't do that, but that
wasn't one of their goals, and it isn't relevant to the C++ standard.
> 2. Which one currently targets more OS's?
Both are implemented on top of pthreads and on top of Win32.
Boost.threads also supports the Mac.
> 3. Which one is more likely to serve as a prototype for inclusion into
> the next revision of ISO/IEC 14882? The reason I ask this one is because
> I know that both PJ Plauger and Pete are in the library working group
> and therefore have influence on the final decision.
>
Boost.Threads. This isn't a competition. <g>
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Alexander Terekhov
Pete Becker wrote:
>
> Kiril Avdeiv wrote:
> >
> > My question is -- does anybody know the following:
> > 1. How compatible the two multithreading libraries are?
>
> Our C++ interface is essentially Boost.Threads. We also provide a
> pthread-like interface in C. Boost.Threads doesn't do that, but that
> wasn't one of their goals, and it isn't relevant to the C++ standard.
Yeah, and likewise (irrelevant w.r.t. C++ standard) is:
Table 12—C++ Headers for C Library Facilities
_____________________________________________________
<cassert> <ciso646> <csetjmp> <cstdio> <ctime>
<cctype> <climits> <csignal> <cstdlib> <cwchar>
<cerrno> <clocale> <cstdarg> <cstring> <cwctype>
<cfloat> <cmath> <cstddef>
_____________________________________________________
Pete, I think that you DO realize that POSIX Threads
IS *standard* (ANSI/IEEE/etc.) extension to *standard*
ANSI-C. So, what am I missing then (w.r.t. the "idea"
of <pthread.h> --> <cthread> transition/adaptation;
another brand new <thread> -- pure C++ header aside)?!
Thank you for clarification in advance!
regards,
alexander.
Peter Dimov
> Kiril Avdeiv wrote:
> > 3. Which one is more likely to serve as a prototype for inclusion into
> > the next revision of ISO/IEC 14882? The reason I ask this one is because
> > I know that both PJ Plauger and Pete are in the library working group
> > and therefore have influence on the final decision.
> >
>
> Boost.Threads. This isn't a competition. <g>
You consider it good enough, then.
Alexander Terekhov
Scott Robert Ladd wrote:
>
> Hi,
>
> For true multiprocessing work on supercomputers and clusters, you can find
> portable libraries like MPI (http://www.mpi-forum.org) and PVM
> (http://www.epm.ornl.gov/pvm/pvm_home.html). I've used MPI quite
> successfully on Beowulf clusters.
>
> Some compilers (Intel, for instance) support the OpenMP
> (http://www.openmp.org/) standard, which is a set of pragmas for
> implementing portable threading in C, C++, and Fortran.
Read this nice write-up on "hints" w.r.t. isolation/security/
performance/scalability/reliability/MPI/OpenMP/threads/processes/
IPC/coarse and fine grained parallelism, etc. (C and C++ mentioned
as well ;-)):
http://groups.google.com/groups?as_umsgid=Jkta8.51%241h5.372%40news.cpqcorp.net
(Motto: "when you design, you make choices. That's what design means!")
> And then there is ZThread (http://zthread.sourceforge.net/news.html), a
> library of C++ classes for threading.
Read also this:
http://groups.google.com/groups?as_umsgid=CAzt8.7%244o5.254068%40cacnews.cac.cpqcorp.net
("Subject: Re: Threads Portability")
Here is the last paragraph:
"However, if the C++ class library isn't implemented
USING the POSIX thread library, then you're cheating
yourself of concurrency and parallelism."
> What you chose depends on your intended design or platform.
Right. (And skills ;-))
regards,
alexander.
Pete Becker
>
> So, what am I missing then (w.r.t. the "idea"
> of <pthread.h> --> <cthread> transition/adaptation;
Some systems don't have pthreads but do support threading.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
---
Pete Becker
>
> Pete Becker <peteb...@acm.org> wrote in message news:<3CBDB1EB...@acm.org>...
> > Kiril Avdeiv wrote:
> > > 3. Which one is more likely to serve as a prototype for inclusion into
> > > the next revision of ISO/IEC 14882? The reason I ask this one is because
> > > I know that both PJ Plauger and Pete are in the library working group
> > > and therefore have influence on the final decision.
> > >
> >
> > Boost.Threads. This isn't a competition. <g>
>
> You consider it good enough, then.
>
I think it's sufficient for the first version of a commercial library
and as a starting point for standardization. I don't know whether more
is needed. I expect to know more after it gets into the field.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
---
Alexander Terekhov
Pete Becker wrote:
>
> Alexander Terekhov wrote:
> >
> > So, what am I missing then (w.r.t. the "idea"
> > of <pthread.h> --> <cthread> transition/adaptation;
>
> Some systems don't have pthreads but do support threading.
Are you saying that it's just impossible to "emulate"
(if you don't like "implement") pthread.h's objects
and calls (support POSIX Threads Programming Model)
on such "some systems"? How about things like
pthreads-win32[1] and pthreads/Apple-OS-X[2]?!
How about your own "We also provide a
pthread-like interface in C" w.r.t. such
"systems"?!
Just to make it clear: I have NO problems with
(I actually *need* it) Boost.Threads-like <thread>
header (but with fixed design errors, much less
pitfalls [I mean smart thread ptrs, for example],
and much more threading stuff from <pthread.h> in
C++ umbrella -- with exceptions, templates, perhaps
even rtti/dynamic_cast for type-safe thread exit,
whatever).
But, PLEASE, <cthread> that would at least throw C++
thread cancel and thread exit exceptions (resolve
all those OLD and KNOWN "pthreads in C++ issues"
and *standardise* it) *FIRST*!
regards,
alexander.
[1] http://sources.redhat.com/pthreads-win32
[2] http://www.opensource.apple.com/bugs/X/Libraries/2686231.html
(see "> So, the history behind this was....")
Pete Becker
>
> Pete Becker wrote:
> >
> > Alexander Terekhov wrote:
> > >
> > > So, what am I missing then (w.r.t. the "idea"
> > > of <pthread.h> --> <cthread> transition/adaptation;
> >
> > Some systems don't have pthreads but do support threading.
>
> Are you saying that it's just impossible to "emulate"
No, just impractical. We don't need all of pthreads.
> But, PLEASE, <cthread> that would at least throw C++
> thread cancel and thread exit exceptions (resolve
> all those OLD and KNOWN "pthreads in C++ issues"
> and *standardise* it) *FIRST*!
It's necessary to get experience with the design before standardizing
it. Otherwise you get a Java-like muddle with some thread operations
unimplemented and others deprecated.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
---
James Kanze
|> > But, PLEASE, <cthread> that would at least throw C++ thread cancel
|> > and thread exit exceptions (resolve all those OLD and KNOWN
|> > "pthreads in C++ issues" and *standardise* it) *FIRST*!
|> It's necessary to get experience with the design before
|> standardizing it. Otherwise you get a Java-like muddle with some
|> thread operations unimplemented and others deprecated.
And no implementation that actually conforms to the "standard". (I
don't think it is possible to implement Java in a conforming manner
using pthreads.)
Note that this isn't really a problem at a practical level, since no one
familiar with threads would expect the standard Java model to actually
work.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481
Alexander Terekhov
Pete Becker wrote:
>
> Alexander Terekhov wrote:
> >
> > Pete Becker wrote:
> > >
> > > Alexander Terekhov wrote:
> > > >
> > > > So, what am I missing then (w.r.t. the "idea"
> > > > of <pthread.h> --> <cthread> transition/adaptation;
> > >
> > > Some systems don't have pthreads but do support threading.
> >
> > Are you saying that it's just impossible to "emulate"
>
> No, just impractical. We don't need all of pthreads.
What are the "We don't need all of pthreads" pieces
you want to "get rid of" from:
http://www.opengroup.org/onlinepubs/007904975/basedefs/pthread.h.html
http://www.opengroup.org/onlinepubs/007904975/basedefs/sched.h.html
<?!>
> > But, PLEASE, <cthread> that would at least throw C++
> > thread cancel and thread exit exceptions (resolve
> > all those OLD and KNOWN "pthreads in C++ issues"
> > and *standardise* it) *FIRST*!
>
> It's necessary to get experience with the design before standardizing
> it. Otherwise you get a Java-like muddle with some thread operations
> unimplemented and others deprecated.
I agree.
Well, I guess, I should really leave it... but as my "closing
remarks" just let me present you the following quotes/opinions
(w.r.t. Boost.Threads and somewhat similar thing IMO; *out of
context and order*[1]):
"So, let's put it this way: it's a good start on
"pthreads with a 'we're C++' attitude". That's good.
I don't think anyone's claiming it's "done" or
"perfect"; feedback and experience will only help."
"I won't argue that I agree with every decision and
limitation in the boost threads package. It's clear
from some subtle details that there were more C++
experts than Thread experts."
"Certainly we broke a lot of existing "DCE thread"
code, but that was because we made a conscious
decision that we would NOT be limited by those
idiots who decided to release a library based on
a draft of a standard that was specifically labelled
"DO NOT IMPLEMENT". (As I've explained before in
this newsgroup, by the way, I can freely use the word
"idiots" as I was one of them. While I'm fairly sure
I couldn't have talked them out of it, my sense of
guilt is rooted in the fact that I didn't even try
because, at the time, it sounded like fun. ;-) )"
And I think that I can freely use/post here (in this
"Re: Boost.Threads..." thread) the quotes with word
"idiots" given:
http://www.boost.org/libs/thread/doc/acknowledgements.html
("Important contributions were also made by ....")
regards,
alexander.
P.S. I wish you a nice weather (and constructive
productive atmosphere in your talks; *threads*
included) in Curacao! ;-)
[1]
http://groups.google.com/groups?as_umsgid=rjAs8.2033%24fL6.54190%40news.cpqcorp.net
http://groups.google.com/groups?as_umsgid=cSNa8.13%24YS1.142%40news.cpqcorp.net
Pete Becker
>
> Pete Becker wrote:
> >
> > Alexander Terekhov wrote:
> > >
> > > Pete Becker wrote:
> > > >
> > > > Alexander Terekhov wrote:
> > > > >
> > > > > So, what am I missing then (w.r.t. the "idea"
> > > > > of <pthread.h> --> <cthread> transition/adaptation;
> > > >
> > > > Some systems don't have pthreads but do support threading.
> > >
> > > Are you saying that it's just impossible to "emulate"
> >
> > No, just impractical. We don't need all of pthreads.
>
> What are the "We don't need all of pthreads" pieces
> you want to "get rid of" from:
>
I don't want to get rid of anything from pthreads. I need a C-callable
threads interface that provides the operations needed for C++ threads.
That's much smaller than pthreads as a whole, and requires a slightly
different interface. The C library provides only what's needed. That
makes both the C library and the C++ library more easily portable to
systems that don't provide pthreads.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
---
Garry Lancaster
> > > > > So, what am I missing then (w.r.t. the "idea"
> > > > > of <pthread.h> --> <cthread> transition/adaptation;
Pete Becker:
> > > > Some systems don't have pthreads but do support threading.
Alexander Terekhov:
> > > Are you saying that it's just impossible to "emulate"
Pete Becker:
> > No, just impractical. We don't need all of pthreads.
Alexander Terekhov:
> What are the "We don't need all of pthreads" pieces
> you want to "get rid of" from:
>
> http://www.opengroup.org/onlinepubs/007904975/basedefs/pthread.h.html
> http://www.opengroup.org/onlinepubs/007904975/basedefs/sched.h.html
>
> <?!>
As we established on the recent "C++ and threads" thread
not all of pthreads can be implemented on some common
thread-aware platforms e.g. Win32. You yourself, Alexander,
wrote that 'Only Microsoft could make it "complete", I mean
FULL implementation of IEEE Std 1003.1-2001.'
Of course, there is no reason a maximally portable subset
of pthreads couldn't form the starting point for the work. If anyone
thinks they know what that subset might be, that could be
a really useful contribution.
(I suggest we not include asynchronous thread cancellation
for reasons that have already been discussed, but other
than that I have no strong opinions on the subject.)
Kind regards
Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net
Kiril Avdeiv
news:3CBDDBC4...@web.de...
Alexander,
Thank you very much for all your insightful explanations and comments!
I found the links very useful too.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
---
Eric D Crahen
> Of course, there is no reason a maximally portable subset
> of pthreads couldn't form the starting point for the work. If anyone
> thinks they know what that subset might be, that could be
> a really useful contribution.
If this subset included deferred cancelation, would it be reasonable to
assume you couldn't really safely implement this using pthreads
cancelation on posix systems? My thinking on this is that in order to get
consistent behavior on non-posix platforms, you'd also have to implement all of
the functions that acts as cancelation points. Let me try to explain my
thoughts,
If you have code that uses recv(), for example, and you invoke your
cancelation mechanism on a posix system (and that mechanism is
implemented using pthreads cancelation) then recv() could be interrtuped.
If you do the same on say a win32 platform, recv() won't ever be interrupted
because the winsock implementation of recv() doesn't support posix
cancelation. You have to implement some sort of wrapper for it to behave
that same.
If you do implement versions of these functions that emulate posix
behavior, you'd have to write a wide variety of functions, like
getcwd(), recv(), etc. for non-posix systems. This is a bunch of functions
that aren't really thread related, or related to each other really, which
seems to leave the realm of a minimal subset. Plus some of these functions
don't really have a meaning on non-posix systems. For example, what would
ttyname() do on Win32 or Mac systems? I suppose you could just supply empty
implementations but it also doesn't seem to fit well with a minimal
implementation, idealy the minimal set would be things that every platform
supports and would be things that actually do something useful.
It'd also be hard to intergrate with existing libraries that aren't linked
against the versions of these functions that are emulating the posix behavoir.
Going back to the winsock example, you might have a 3rd party library that
provides abstractions for network i/o; for win32 they implement it using
WASSend & WSARecv, and for posix they implement it with recv() & send().
So now you add code for threads that uses real posix canceltion on posix
systems and provides posix like wrappers for win32. But the 3rd party library
can't be changed is using winsock. Now you start canceling threads which is
stopping i/o on posix but not on win32, it will just complicate
writing a program with consistent behavoir.
For a moment suppose you sucessfully create perfect wrappers that emulate
posix cancelation on non-posix systems and use posix cancelation on posix
systems. But also suppose you have a cross platform program
that relies on some windows specific I/O functions to get the maximum
performance using completion ports and other windows specific stuff for
win32 implementations & it has a posix implementation that relies on alot
of posix functions to try and maximize performance there. This code might
use cancelation on posix systems but it can't use the wrappers for win32
because its heavily using win32 functions. So it needs to use windows
specific things to deal with interrupting its i/o on that platform. So you
have a situation where even though you provide similar behavor, there is
still more than one way to do something (because you can't eliminate
the existings apis that the emulated functions might be built on) and it
might be more efficent to do things the other (win32 specific) way. This
would always be true whenever you make some kind of portable abstraction,
but in this case its a little more exagerrated. If you use an I/O
abstraction its reasonable to limit yourself to only that abstraction
(because if you didn't, why are you using the abstraction)
but with a thread abstraction that simulates posix canceltion reaches out
into other non-thread areas (i/o, user & group, file system, ...) and it
becomes less apparent what functions you can still use to get consistent behavior.
All the thread related functions are obvious (you're aware your using a
thread abstraction, afterall), but the io functions, for example, arent as
obvious. You'd have a common getcwd() function in order to keep canceltion
working consistently, but there wouldn't be a common set of functions to walk
through a directory structure. Because of that you might tend to forget that
you should use the getcwd() wrapepr if you want the programs be as
consistent as possible. The same goes for the socket functions which can
be drastically different on different platforms. You might get the
abstraction 100% correct, but its not really unified its sense of purpose
in some ways because it involves alot of different kinds of functions.
You might chalk it up to being the programmers problem, but even if you
do do this, it would be limiting. The library might impose alot of
restrictions (you have to use the recv() & getcwd() wrappers if
consistency is important, etc.) and it might just be easier for someone
trying to create this type of example program to use whatever native
threads are there. They'd end up with a protable application in the end
still, but it would be more difficult ot maintain because they have to
keep the i/o code up to date, but now also the thread code up to date.
(There is probably a better way to design this kind of program, but this
is just an example)
If the purpose of defining a minimal subset of functions is to increase
portablity, alot of care will have to be taken to make sure the subset
will work correctly; not only the sense that it has to be possible to
implement but also in that it has to make sense on all those platforms.
Otherwise, you'll end up with alot of subtle differences that detract from
the overall utility of the portable thread primatives. Maybe this has
already been addressed, but I have only recently began to read this group
and never really saw a formal discussion about it.
You could still create something that would have the effects of
cancelation if you restrict the supported cancelation points to something
within the scope of the thread library, like functions that have the
potential to cause a blocking wait on a synchronization object.
I haven't really thought about async cancellation yet.
- Eric
http://www.cse.buffalo.edu/~crahen
Alexander Terekhov
Garry Lancaster wrote:
[...]
> As we established on the recent "C++ and threads" thread
> not all of pthreads can be implemented on some common
> thread-aware platforms e.g. Win32. You yourself, Alexander,
> wrote that 'Only Microsoft could make it "complete", I mean
> FULL implementation of IEEE Std 1003.1-2001.'
I meant QOI (Quality of Implementation) issues and actually this:
http://groups.google.com/groups?as_umsgid=3CBC1A30.EF89B4BF%40web.de
"....
As for Microsoft... if I'd be a US citizen, I'd rather
petition my Senator/Attorney General/etc. and/or DOJ
requesting the *enforced* MS commitment to:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwbgen/html/msdn_posix.asp
as a part of the antitrust case settlement and/or
punishment remedy!! ;-) ;-) ...."
> Of course, there is no reason a maximally portable subset
> of pthreads couldn't form the starting point for the work. If anyone
> thinks they know what that subset might be, that could be
> a really useful contribution.
I think I know what that "subset" SHOULD be:
A) 100% of pthreads/C in <cthread>;
B) Better pthreads "bindings" (with exceptions, templates [built-in
binder in 'thread factories'], rtti for type-safe thread-exit,
"smart thread ptrs" [get rid of "detach" thing], scoped locking
guards, etc.) in <thread>... "compatible" w.r.t. <cthread>, I
mean things along the lines of: pthread_mutex_t* mutex::c_mutex(),
etc.
> (I suggest we not include asynchronous thread cancellation
> for reasons that have already been discussed,
http://groups.google.com/groups?as_umsgid=3C926C82.AD56845D%40web.de
("// 'safe' async-cancel/bool expected_exception< cancel_e >()
'illustration'")
http://groups.google.com/groups?as_umsgid=3CB6A1B9.63D38341%40web.de
(Subject: Re: Fastest thread communication with pthreads?)
"Hillel Y. Sims" wrote:
>
> or you could just pthread_cancel the searcher thread, and it will die when
> it reaches the next cancellation point (you can even manually
> pthread_testcancel() at various points in the searcher thread if you want to
> make sure it dies by a certain point)
Yeah, and given the nature of work in the "searcher thread",
it is likely that you could have A LOT of *async-cancel-safe*
places (with loops; long computations) in it. Just set the
cancel type to PTHREAD_CANCEL_ASYNCHRONOUS on entry and set
it back to PTHREAD_CANCEL_DEFERRED on exit of such region
(and please, *don't* code anything non-async-cancel-safe
inside it ;-)). No "periodically checking" then needed
(inside async-canel-regions)... and it even works on
WinBlahBlah "platforms":
http://sources.redhat.com/pthreads-win32/
;-)
Aahh, well... it would be *really* GREAT if *Boost.Threads*
would have/provide "something like that" as well! ;-) ;-)
IMHO.
regards,
alexander.
Hillel Y. Sims
"Garry Lancaster" <glanc...@ntlworld.com> wrote in message
news:nDWv8.3402$ML.5...@news2-win.server.ntlworld.com...
> (I suggest we not include asynchronous thread cancellation
> for reasons that have already been discussed, but other
> than that I have no strong opinions on the subject.)
>
What reasons? I thought there was some growing acceptance that it could
actually be done with fairly reasonable semantics in C++ if using a
pthread-style cancellation paradigm (not asynchronous, by default) to model
it.
hys
--
Hillel Y. Sims
hsims AT factset.com
Garry Lancaster
> > As we established on the recent "C++ and threads" thread
> > not all of pthreads can be implemented on some common
> > thread-aware platforms e.g. Win32. You yourself, Alexander,
> > wrote that 'Only Microsoft could make it "complete", I mean
> > FULL implementation of IEEE Std 1003.1-2001.'
Alexander Terekhov:
> I meant QOI (Quality of Implementation) issues
How does QoI affect whether it's a complete
implementation or not?
> and actually this:
>
> http://groups.google.com/groups?as_umsgid=3CBC1A30.EF89B4BF%40web.de
>
> "....
> As for Microsoft... if I'd be a US citizen, I'd rather
> petition my Senator/Attorney General/etc. and/or DOJ
> requesting the *enforced* MS commitment to:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwbgen/htm
l/msdn_posix.asp
I got an MSDN "Page cannot be found" page when I tried
this link :-(
> as a part of the antitrust case settlement and/or
> punishment remedy!! ;-) ;-) ...."
The US govenment is rather unlikely to force MS to
implement complete pthreads. It would make
things simpler, but it is really just wishful thinking.
Kind regards
Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net
---
Garry Lancaster
> > (I suggest we not include asynchronous thread cancellation
> > for reasons that have already been discussed, but other
> > than that I have no strong opinions on the subject.)
Hillel Y. Sims:
> What reasons? I thought there was some growing acceptance
> that it could actually be done with fairly reasonable semantics
> in C++ if using a pthread-style cancellation paradigm (not
> asynchronous, by default) to model it.
First of all, it's the *asynchronous* cancellation I don't want:
specifically the idea that thread A can inject a C++ exception
into thread B without thread B's intervention. Synchronous
thread cancellation is fine, indeed I view it as a desirable
feature.
Also, I agree that asynchronous thread cancellation could
be done, at least on some processors. Rather, I just don't believe
it is worth the trouble, as I explained in the "C++ and threads"
thread, in particular in this message:
http://groups.google.com/groups?q=g:thl1161693854d&dq=&hl=en&selm=x9Jg8.9161
2%24Ah1.12641823%40news2-win.server.ntlworld.com
(You need to paste the two lines back together.)
Kind regards
Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net
---