CUJ/"The Boost.Threads Library" article - feedback/comments?!
Hillel Y. Sims
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3CB14C2F...@web.de...
>
> Care to provide some "feedback"/"comments", folks?
>
> (I'll do it in the reply to this message sometime
> later, and would greatly appreciate if you could
> be so kind and share your opinions too.)
>
> The library:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/thread/
> The docu: http://www.boost.org/libs/thread/doc/index.html
>
> Article: http://www.cuj.com/current/feature.htm?topic=current
>
> ====
>
> The Boost.Threads Library
>
> Bill Kempf
>
> Standard C++ threads are imminent. CUJ
> predicts they will derive from the Boost.Threads
> library, explored here by the eminent author.
>
Alexander Terekhov
Alexander Terekhov wrote:
>
> Care to provide some "feedback"/"comments", folks?
>
> (I'll do it in the reply to this message sometime
> later, and would greatly appreciate if you could
> be so kind and share your opinions too.)
>
> The library:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/thread/
> The docu: http://www.boost.org/libs/thread/doc/index.html
>
> Article: http://www.cuj.com/current/feature.htm?topic=current
>
> ====
>
> The Boost.Threads Library
>
> Bill Kempf
>
> Standard C++ threads are imminent. CUJ
> predicts they will derive from the Boost.Threads
> library, explored here by the eminent author.
>
Briefly, Boost.Threads is nothing more than
a thin, very thin objects layer (actually mostly
"scoped locking pattern" -- a few ctors/dtors)
added on top of sort-of-castrated Pthreads
programming model/concepts. It lacks a lot
(w.r.t "full"/"official" Pthreads)... and screws
up a lot (such as the concept of thread objects
("invisible" in Pthreads/C and their id/refs
represented by *process-wide* pthread_t objs,
etc, etc). Some details/comments follow.
> The C++ Standard doesn't mention
> threads, leaving programmers to
> wonder whether it's even possible to
> write multithreaded C++ programs.
> Though it is not possible to write
> standards-compliant multithreaded
> programs, programmers none the
> less write multithreaded programs in
> C++ using the libraries provided by
> their OS that expose the system's
> support for threads. However, there
> are at least two major problems with
> doing this: these libraries are almost
> universally C libraries and require
> careful use in C++, and each OS
> provides its own set of libraries for
> handling multithreaded support.
> Therefore, the resulting code is not
> only non-standard, but also non-
> portable [1].
[1] Note:
> [1] The POSIX standard defines multithreaded
> support in what's commonly known as the
> pthread library. This provides multithreaded
> support for a wide range of operating systems,
> including Win32 through the pthreads-win32
> port. However, this is a C library that fails
> to address some C++ concepts and is not available
> on all platforms.
This is just a silly attempt to justify the total
ignorance (and forking) of pthreads-win32 LGPL project.
Pthreads is the only standard covering low level MT
programing in C out there. It is simple and reasonable.
Everyone (except MS) does serious C/C++ threading (cancel/
exit in C++ and some language issues aside) in *Pthreads*.
pthreads-win32 DOES address/implements A LOT of Pthreads
stuff and tries to be fully compliant with the official
specs. Boost.Threads DOES NOT.
Note that this has nothing to do with a need for a more
convenient OO/C++ "wrappers" for Pthreads/C; something
along the lines, just an "illustration":
mutex mtx( mutex::attr().set_type( mutex::ERRORCHECK ) );
// non-void thread routine with some args
result = *thread::attr().set_name( "blahblah" )
.set_schedpolicy( sched::FIFO )
.new_thread( routine,
...arguments... );
> Boost.Threads is a
> library designed to address both
> problems.
No. The STANDARD (POSIX/PThreads part of it)
is designed to address the portability problem.
Boost.Threads (in its current form) neither
addresses the problem of integration of various
C++ features (exceptions/static locals/etc)
with threads, nor does it address the problem
of "++"-ing of FULL "versions" of pthread.h/sched.h
BUT keeping/providing compatibility for zillions
Pthreads/C (and C++) lines of code out there.
> Many C++ experts provided input to
> the design of Boost.Threads. The
> interface was designed from the
> ground up and is not just a simple
> wrapper around any C threading
> API. Many features of C++ (such as
> the existence of
> constructors/destructors, function
> objects, and templates) were fully
> utilized to make the interface more
> flexible. The current implementation
> works for POSIX, Win32, and Macintosh
> Carbon platforms.
"Carbon platform"! Oh, boy. FYI:
http://www.opensource.apple.com/bugs/X/Libraries/2686231.html
<mwa...@apple.com> wrote:
"....
> So, the history behind this was that we needed a real spec from which
to
> base OS X's threading model. We chose pthreads, taking some of the
> implementation from an existing OSF port. The resulting code evolved
> "on-demand" as the requirements of the higher-level (Carbon, Cocoa,
> Java) threading packages required."
Well, you know, I also have a lot to say about
the following "technicalities" (just a few brief
"remarks" follow below):
> Thread Creation
>
> The boost::thread class represents
(*&()*&*(
>
> Mutexes
>
"Timed mutex" for pthreads is just a silly
semaphore (condvar based). Gee! How are you
going to program monitors with this beast?!
> It appears that the best possible
> mutex type is a recursive type that
> allows all three forms of locking.
> However, overhead is involved with
> each variation, so Boost.Threads
> allows you to pick the most efficient
> mutex type for your specific needs.
> This leaves Boost.Threads with six
> mutex types, listed in order of
> preference based on efficiency:
> boost::mutex, boost::try_mutex,
> boost::timed_mutex,
> boost::recursive_mutex,
> boost::recursive_try_mutex, and
> boost::recursive_timed_mutex.
(Well, just can't resist: why the hell
you need all those zillions of static
mutex types!? Pthreads has a nice concept
of various pthread objects attrs!!)
> difficult). No direct access to
> operations for locking and unlocking
> any of the mutex types is available.
> Instead, mutex classes define nested
> typedefs for types that implement
> the RAII (Resource Acquisition in
> Initialization) idiom for locking
> and unlocking a mutex. This is known
> as the Scoped Lock [4] pattern. To
^^^^^^^^^^^
8-0 It is "scoped locking"/guards to begin
with. But Boost.Threads invented really
something new and exciting: NON-SHAREABLE
LOCK *OBJECTS*. Gee!
> Condition Variables
Win32 version destructor is wrong/non-compliant, to begin with.
> Thread Local Storage
Does NOT even come close to Java's ThreadLocals!
> Once Routines
"Impl" sucks:
#elif defined(BOOST_HAS_PTHREADS)
pthread_once(&once, &key_init);
pthread_setspecific(key, &func);
pthread_once(&flag, do_once);
(lack of proper memory synch/visibility for Win versions aside)
etc, etc... which I've mentioned multiple times on the boost.org
dev.mailing-list... No one listened. Well, fine.
MY SUMMARY: DON'T USE IT; IT IS CURRENTLY SIMPLY A "JOKE", IMHO.
regards,
alexander.
Alexander Terekhov
> It's basically pthreads with a "we're not pthreads" attitude..
I'd rather say/characterize it as:
It's basically a rather COMIC/failed attempt to REINVENT
pthreads with "Huh? What "pthreads"? We don't care/We're
in total ignorance of pthreads and standards and all those
working groups/clever people who spent a lot of time on
it -- designing and reaching consensus with respect to a
simple and reasonable and easily portable/implementable
threading model/API" attitude.
Well, but to be fair, it is NOT the worse thing that
could have possibly happened given that the author&co
coming with Win32-only backgrounds DID recognize the
silliness and total absurdity of MS-specific threading
stuff along the lines of MS-events/semas/interlocked/
async.suspend/termthread/waitformultiple/etc stuff with
respect to portable, shared memory concurrent low level
programming.
;-)
regards,
alexander.
Alexander Terekhov
way-toooo-"on-topic" climate over there... after a couple
of days spent on c.l.c++! >
Pete Becker <peteb...@acm.org> wrote in message news:<3CB232E0...@acm.org>...
> > Alexander Terekhov wrote:
> > >
> > > Care to provide some "feedback"/"comments", folks?
> > >
>
> Sure. Don't violate copyright law by posting someone else's copyrighted
> text.
Thanks. FYI: (somewhere/sometime in the cyberspace)
"[C]opying . . . the entire work for a different functional purpose
may be regarded as fair use." M. Nimmer & D. Nimmer, 4 Nimmer on
Copyright § 13.05[D][1] (1999).
Among the many "different functional purpose" cases reported by
Nimmer, Haberman v. Hustler Magazine, Inc., 626 F. Supp. 201 (D. Mass.
1986) found Hustler Magazine's reproduction of two photographs in
their entirety to be fair. The magazine's purpose was to entertain
its readers. There were no damages, no supplanting of the
photographer's market.
In Belmore v. City Pages, Inc., 880 F. Supp. 673 (D. Minn. 1995), a
police officer (Belmore) wrote a short article that was published in a
police union newspaper. City Pages republished Belmore's entire
article, preceded and succeeded by critical commentary. City Pages'
stated purpose was to criticize a "transparently racist" article by a
police officer. Id. at 678 n.4.
As the City Pages editor put it, "[my] purpose in reprinting the
entire article was . . . to ensure that my readers understood what I
was criticizing . . . ." Id. at 679. The court agreed, finding the
reprinting of the entire article to be "reasonable":
"[A]lthough wholesale copying militates against a finding of fair use,
this factor does not have significant weight when applied to the
unique facts presented in this case."
regards,
alexander.
---
This post is copyright 2001 by Alexander Terekhov. It may not be
reproduced in part of in full through any type of media, including
electronic media, without the express written consent of the author.
P.J. Plauger
> Pete Becker <peteb...@acm.org> wrote in message news:<3CB232E0...@acm.org>...
> > > Alexander Terekhov wrote:
> > > >
> > > > Care to provide some "feedback"/"comments", folks?
> > > >
> >
> > Sure. Don't violate copyright law by posting someone else's copyrighted
> > text.
>
> Thanks. FYI: (somewhere/sometime in the cyberspace)
>
> "[C]opying . . . the entire work for a different functional purpose
> may be regarded as fair use." M. Nimmer & D. Nimmer, 4 Nimmer on
> Copyright § 13.05[D][1] (1999).
> ..... [etc., ad nauseam]
Nice citations. But you just got some accurate and free advice from a
lawyer, author, and computer expert. You'd be well advised to take it,
before you have to pay some lawyer real $ to defend your butt.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
David Butenhof
> It's basically pthreads with a "we're not pthreads" attitude..
You say that almost as if you think that's bad.
What we're all used to as "Pthreads" is, explicitly and by design, the C
LANGUAGE binding to the core essential capabilities of "a thread library".
Nobody ever intended that all languages would share the C language binding.
In fact, we always intended that each language SHOULD devise its own
binding that makes sense. And we always knew that C++ should have a binding
that utiliizes the full capabilities of the language; including,
especially, objects and exceptions.
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. Still, I don't see anything terribly bad
about it, and it's got the essentials such as scoped mutex guard classes.
Thread groups are nice, as they allow something like the "join all"
capability so many like from Solaris... redesigned so it can actually work.
(By acting on a specifically created group, rather than on all threads in
the process.) Boost has taken "default" and "recursive" mutexes, and that's
OK despite the fact that the wording of the description implies someone
thinks recursive mutexes must be better except for being more expensive. No
error check mutexes; but that's OK, too. There are some ambiguities around
the condition variable methods, but again there are some good ideas.
There are other aspects of POSIX/UNIX 98 they don't address because they're
trying to maintain compatibility with inferior threading models. ( ;-) )
Well, the C++ language specification can't be "UNIX only", after all, so
the more advanced and unique aspects of the POSIX standard must be
approached with some caution. Even if the initial C++ specification for
thread support doesn't cover 100% of the thread standard, it'll still be
far better than what people can now count on in doing portable C++ threaded
development, and that's all to the good. The reality is that there are far
more Win32 programmers than people doing REAL threaded development. (I'll
add a pro-forma ;-) here, though I'm less convinced I should consider this
one a joke. OK, that's almost another ;-) in itself...)
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.
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/
Hillel Y. Sims
"David Butenhof" <David.B...@compaq.com> wrote in message
news:rjAs8.2033$fL6....@news.cpqcorp.net...
> Hillel Y. Sims wrote:
>
> > It's basically pthreads with a "we're not pthreads" attitude..
>
> You say that almost as if you think that's bad.
>
Not necessarily, just the impression I got from the article (once routines,
etc). At our site, we have our own custom inhouse C++ threads library (8+
years old) which wraps VMS cma/pthread layer, to which much of boost.threads
has quite a high degree of similarity really (but in a number of respects
boost probably has some superior constructs). I haven't got nearly enough
experience with the boost library to pronounce judgment on whether I think
it's good or bad. I do agree it's good that they left out the Win32-style
stuff ;-)
hys
William E. Kempf
news:rjAs8.2033$fL6....@news.cpqcorp.net...
>
> > It's basically pthreads with a "we're not pthreads" attitude..
No, it's not a "we're not pthreads" attitude. It's a "we're C++ not C"
attitude. There's a reason that a lot of the semantics are POSIX like...
because POSIX is a very well designed library with few "warts". However,
it's a C MT binding, and a C++ MT binding has different needs.
Boost.Threads was designed as much as possible to not lock itself into the
paradigm of any one existing C bindings in order to rediscover how best to
apply MT concepts to the C++ language.
Is it anything new or revolutionary? No. That was never the goal.
> You say that almost as if you think that's bad.
>
> What we're all used to as "Pthreads" is, explicitly and by design, the C
> LANGUAGE binding to the core essential capabilities of "a thread library".
> Nobody ever intended that all languages would share the C language
binding.
> In fact, we always intended that each language SHOULD devise its own
> binding that makes sense. And we always knew that C++ should have a
binding
> that utiliizes the full capabilities of the language; including,
> especially, objects and exceptions.
Thank you, Mr. Butenhof. That paragraph summarizes the goals of
Boost.Threads much better then I ever have in the past.
> 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.
Yes. And in the early stages of the library I think this was a good thing.
We're about ready to enter a new phase with the library, however, where I
will be calling on those with more MT expertise to take the library apart at
the seams and put it back together again in. I hope you and others will
vounteer to help in this phase.
> Still, I don't see anything terribly bad
> about it, and it's got the essentials such as scoped mutex guard classes.
> Thread groups are nice, as they allow something like the "join all"
> capability so many like from Solaris... redesigned so it can actually
work.
> (By acting on a specifically created group, rather than on all threads in
> the process.) Boost has taken "default" and "recursive" mutexes, and
that's
> OK despite the fact that the wording of the description implies someone
> thinks recursive mutexes must be better except for being more expensive.
Oops... I can see how this can be miscronstrued from my wording. Not
precisely what I believe. I do believe that recursive mutexes often play a
much bigger role in OO languages... the work required to create a MT object
interface is complicated if you can't directly call other methods on the
object internally with out fear of deadlock. The "Thread Safe Interface"
pattern (POSA2) provides the optimal solution to this problem for a lot of
reasons. However, it also complicates the implementation enough to be
disliked for general use. Maybe not the strongest argument for recursive
mutexes, but it is a factor to consider. If you read the documentation,
however, you do see that recursive mutexes are discouraged for general use.
> No
> error check mutexes; but that's OK, too.
The documentation explicitly allows any of the mutex types to be error
checked. The "correct" solution when submitted for standardization (if the
committee is still interested in this particular library at that time) is to
specify an explicit error checked version. But the difficulties in
providing this "portably" was the reason for leaving this out in the current
incarnation of the library.
> There are some ambiguities around
> the condition variable methods, but again there are some good ideas.
I'm not totally pleased with the state of boost::condition... it's one of
the concepts that needs a lot of work yet. I'd be interested in hearing
some of your opinions on this topic. This particular thread probably isn't
the place, but feel free to e-mail me directly or to start a new thread here
or on the Boost list.
> There are other aspects of POSIX/UNIX 98 they don't address because
they're
> trying to maintain compatibility with inferior threading models. ( ;-) )
*chuckles* Yes, we have a few constraints because of portability. I've
been trying to note these... if Boost.Threads is the basis for
standardization these issues can be dealt with more easily there, where we
can have some influence on platform specific implementation issues.
Again, I'd be very happy to hear some of your specific points in these
areas.
> Well, the C++ language specification can't be "UNIX only", after all, so
> the more advanced and unique aspects of the POSIX standard must be
> approached with some caution. Even if the initial C++ specification for
> thread support doesn't cover 100% of the thread standard, it'll still be
> far better than what people can now count on in doing portable C++
threaded
> development, and that's all to the good. The reality is that there are far
> more Win32 programmers than people doing REAL threaded development. (I'll
> add a pro-forma ;-) here, though I'm less convinced I should consider this
> one a joke. OK, that's almost another ;-) in itself...)
You know, this is actually a subject I'd like to discuss at length as well.
I'm a Windows developer, but when it came to MT I learned long ago that
there are some very ugly warts in the API provided for MT in Win32 (despite
claims by others that I came to this realization while working on
Boost.Threads, I actually learned this within a few months of learning the
Win32 API). However, there are a few "interesting" features present in the
Win32 API that may warrant at least some thought. For instance, the
WaitForMultipleObjects API can be put to very strong use, and there have
been a few papers on this by MT experts that indicate some performance gains
can be achieved through it. This concept is totally missing from
Boost.Threads because of portability reasons, and though I won't go so far
as to suggest that it should be included I would like to at least explore
the pros/cons of this concept.
> 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.
It's is *FAR* from done... and it's too new to warrant the label of
"perfect". I'll be happy if people label it "usable".
Thanks, to both of you, for your comments.
Bill Kempf
Alexander Terekhov
You, Mr. Plauger (and Mr. Becker) won't impress me
much with your high grade Latin and "real $ to defend
your butt" remarks.
You know, in my humble opinion, you could earn a lot
more credit and respect if both of you would join and
demonstrate your all-around-talents ("on-topic"), in
these discussions:
http://groups.google.com/groups?threadm=3CB14C2F.349AEF75%40web.de
http://groups.google.com/groups?threadm=3C7BD6B3.1EAE29D0%40web.de
like, for example, Mr. Butenhof (a-sort-of-unknown in the
threading business ;-)) did. And hey, even Mr.Kempf (isn't
*he* the copyright owner here, btw?) did finally show up himself
on the "right" forum/discussion -- the one he could have chosen
himself many, many months ago... if he would "agree" to take a
free advice from me-NOT-a-lawyer-author-and-computer-expert (and,
btw, back then, that was done in a much more "polite"/less-
"challenging"-in-public form than I've adopted recently -- after
all those numerous and failed attempts pointing to the "right"
MT programming model, most common Pthreads/C-pitfalls, etc...
C++ language specific issues/bindings -- what-is-the-best-way-
to-wrap-it-in-C++ aside).
regards,
alexander.
Dragan Cvetkovic
> "P.J. Plauger" wrote:
> > Nice citations. But you just got some accurate and free advice from a
> > lawyer, author, and computer expert. You'd be well advised to take it,
> > before you have to pay some lawyer real $ to defend your butt.
>
> You, Mr. Plauger (and Mr. Becker) won't impress me
> much with your high grade Latin and "real $ to defend
> your butt" remarks.
>
> You know, in my humble opinion, you could earn a lot
> more credit and respect if both of you would join and
> demonstrate your all-around-talents ("on-topic"), in
> these discussions:
>
> http://groups.google.com/groups?threadm=3CB14C2F.349AEF75%40web.de
> http://groups.google.com/groups?threadm=3C7BD6B3.1EAE29D0%40web.de
>
Well, I think that Mr. Plauger already has more than enough credits. If you
don't know who he is, ask around.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
Pete Becker
>
> And hey, even Mr.Kempf (isn't
> *he* the copyright owner here, btw?)
It's easy enough to find out. Just go to the CUJ web site and see that
the copyright notice at the bottom of the page that has this article
says "Copyright (c) 2002 C/C++ Users Journal".
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Alexander Terekhov
[...]
> There are other aspects of POSIX/UNIX 98 they don't address because they're
> trying to maintain compatibility with inferior threading models. ( ;-) )
I can't speak for Apple (and, BTW, I guess that THEY have much
easier job), but here is the "Pthreads-supported" stuff from the
"Level of standards conformance" page of pthreads-****win32****;
the only non-PTHREADS (or "non-ALMOST-PTHREADS" like Linux, and,
except Apple) platform addressed by current version of Boost.Threads:
http://sources.redhat.com/pthreads-win32/conformance.html
Level of standards conformance
------------------------------
The following POSIX 1003.1 2001 options are defined:
_POSIX_THREADS
_POSIX_THREAD_SAFE_FUNCTIONS
_POSIX_THREAD_ATTR_STACKSIZE
_POSIX_THREAD_PRIORITY_SCHEDULING
_POSIX_READER_WRITER_LOCKS
_POSIX_SPIN_LOCKS
_POSIX_BARRIERS
The following functions are implemented:
---------------------------
PThreads
---------------------------
pthread_attr_init
pthread_attr_destroy
pthread_attr_getdetachstate
pthread_attr_getstackaddr
pthread_attr_getstacksize
pthread_attr_setdetachstate
pthread_attr_setstackaddr
pthread_attr_setstacksize
pthread_create
pthread_detach
pthread_equal
pthread_exit
pthread_join
pthread_once
pthread_self
pthread_cancel
pthread_cleanup_pop
pthread_cleanup_push
pthread_setcancelstate
pthread_setcanceltype
pthread_testcancel
---------------------------
Thread Specific Data
---------------------------
pthread_key_create
pthread_key_delete
pthread_setspecific
pthread_getspecific
---------------------------
Mutexes
---------------------------
pthread_mutexattr_init
pthread_mutexattr_destroy
pthread_mutexattr_getpshared
pthread_mutexattr_setpshared
pthread_mutexattr_gettype
pthread_mutexattr_settype (types: PTHREAD_MUTEX_DEFAULT
PTHREAD_MUTEX_NORMAL
PTHREAD_MUTEX_ERRORCHECK
PTHREAD_MUTEX_RECURSIVE )
pthread_mutex_init
pthread_mutex_destroy
pthread_mutex_lock
pthread_mutex_trylock
pthread_mutex_timedlock
pthread_mutex_unlock
---------------------------
Condition Variables
---------------------------
pthread_condattr_init
pthread_condattr_destroy
pthread_condattr_getpshared
pthread_condattr_setpshared
pthread_cond_init
pthread_cond_destroy
pthread_cond_wait
pthread_cond_timedwait
pthread_cond_signal
pthread_cond_broadcast
---------------------------
Read/Write Locks
---------------------------
pthread_rwlock_init
pthread_rwlock_destroy
pthread_rwlock_tryrdlock
pthread_rwlock_trywrlock
pthread_rwlock_rdlock
pthread_rwlock_timedrdlock
pthread_rwlock_rwlock
pthread_rwlock_timedwrlock
pthread_rwlock_unlock
pthread_rwlockattr_init
pthread_rwlockattr_destroy
pthread_rwlockattr_getpshared
pthread_rwlockattr_setpshared
---------------------------
Spin Locks
---------------------------
pthread_spin_init
pthread_spin_destroy
pthread_spin_lock
pthread_spin_unlock
pthread_spin_trylock
---------------------------
Barriers
---------------------------
pthread_barrier_init
pthread_barrier_destroy
pthread_barrier_wait
pthread_barrierattr_init
pthread_barrierattr_destroy
pthread_barrierattr_getpshared
pthread_barrierattr_setpshared
---------------------------
RealTime Scheduling
---------------------------
pthread_attr_getschedparam
pthread_attr_setschedparam
pthread_attr_getinheritsched
pthread_attr_setinheritsched
pthread_attr_getschedpolicy (only supports SCHED_OTHER)
pthread_attr_setschedpolicy (only supports SCHED_OTHER)
pthread_getschedparam
pthread_setschedparam
pthread_getconcurrency
pthread_setconcurrency
pthread_attr_getscope
pthread_attr_setscope (only supports PTHREAD_SCOPE_SYSTEM)
sched_get_priority_max
sched_get_priority_min
sched_rr_get_interval (returns an error ENOTSUP)
sched_setscheduler (only supports SCHED_OTHER)
sched_getscheduler (only supports SCHED_OTHER)
sched_yield
---------------------------
Signals
---------------------------
pthread_sigmask
---------------------------
Non-portable routines (see the README.NONPORTABLE file for usage)
---------------------------
pthread_getw32threadhandle_np
pthread_timechange_handler_np
pthread_delay_np
pthread_mutexattr_getkind_np
pthread_mutexattr_setkind_np (types: PTHREAD_MUTEX_FAST_NP,
PTHREAD_MUTEX_ERRORCHECK_NP,
PTHREAD_MUTEX_RECURSIVE_NP,
PTHREAD_MUTEX_ADAPTIVE_NP,
PTHREAD_MUTEX_TIMED_NP)
pthread_num_processors_np
pthread_win32_process_attach_np (Required when statically linking
the library)
pthread_win32_process_detach_np (Required when statically linking
the library)
pthread_win32_thread_attach_np (Required when statically linking
the library)
pthread_win32_thread_detach_np (Required when statically linking
the library)
---------------------------
Static Initializers
---------------------------
PTHREAD_ONCE_INIT
PTHREAD_MUTEX_INITIALIZER
PTHREAD_COND_INITIALIZER
PTHREAD_RWLOCK_INITIALIZER
PTHREAD_SPINLOCK_INITIALIZER
---------------------------
Thread-Safe C Runtime Library (macros)
---------------------------
strtok_r
asctime_r
ctime_r
gmtime_r
localtime_r
rand_r
So, my question is:
A) Why not "wrap" THAT functionality in C++ with objects and
exceptions and templates and true-polymorphism and whatever
RIGHT NOW -- TODAY (and *preserving* compatibility with
respect to *existing* Pthreads/C "modules" written in C
*AND/OR* C++ using Pthreads/C API)?!
B) Why not base the Win32 Boost.Threads distribution package
on *pthreads-win32* package (perhaps even included), WHY
DUPLICATE THE CODE, SUPPORT EFFORTS, etc -- "FORKING" it?!
TIA.
regards,
alexander.
Default User
> You know, in my humble opinion,
Ha ha ha. Humble. Ha.
> you could earn a lot
> more credit and respect if both of you would join and
> demonstrate your all-around-talents ("on-topic"), in
> these discussions:
I don't think either of these gentlemen need to worry about the level of
respect they've earned in the community.
You on the other hand, have proven yourself to be a newsgroup troll,
with a scant level of knowledge just sufficient to blather on and on,
but without any real understanding of the subjects.
Brian Rodenborn
Keith Willis
<tere...@web.de> wrote:
>You, Mr. Plauger (and Mr. Becker) won't impress me
>much with your high grade Latin and "real $ to defend
>your butt" remarks.
>
<sigh...>
Guys, take it to email, ferkrissake.
<Engaging 'Ignore thread' button...>
--
PGP key ID 0xEB7180EC
Available from http://www.keyserver.net
Mike Hewson
> You, Mr. Plauger (and Mr. Becker) won't impress me
> much with your high grade Latin and "real $ to defend
> your butt" remarks.
>
> You know, in my humble opinion, you could earn a lot
> more credit and respect if both of you would join and
> demonstrate your all-around-talents ("on-topic"), in
> these discussions:
Don't be so humble, you're not that great.
Now be a good chap, do piss off and stop trolling.
--
No Cheers
--
Hewson::Mike
"I have made this letter longer than usual because I lack
the time to make it shorter."
- Blaise Pascal
FAQ's
alt.comp.lang.learn.c-c++ : http://snurse-l.org/acllc-c++/faq
comp.lang.c++ : http://www.parashift.com/c++-faq-lite/
Alexander Terekhov
> Alexander Terekhov wrote:
> >
> > And hey, even Mr.Kempf (isn't
> > *he* the copyright owner here, btw?)
>
> It's easy enough to find out. Just go to the CUJ web site and see that
> the copyright notice at the bottom of the page that has this article
> says "Copyright (c) 2002 C/C++ Users Journal".
That's even better. Just go to the source of the "[etc., ad nauseam]
Nice citations" and carefully study that misc.legal[1] stuff. The
thread is called "Copyright question about clip and pasting articles
to discussion news groups":
http://groups.google.com/groups?threadm=ik4b6u40se5pi3ap0aiktop7ncf5jo6t2e%404ax.com
Please, pay some attention w.r.t things like "url back to the
original source is always included with the post", "In that
sense, you may increase the revenue to the copyright owner.",
"his purposes include commentary and education", etc.
regards,
alexander.
[1] Well, but there are some posts even going to/from "alt.censorship,
alt.law-enforcement, alt.lawyers, aus.legal, can.legal, misc.legal,
uk.legal, us.legal" ;-)
Mike Hewson
news:lm1ydo8...@lokrum.tor.soliton.com...
> Well, I think that Mr. Plauger already has more than enough credits. If
you
> don't know who he is, ask around.
I'll go one better, at the bottom of many include files for my C++
implementation is something like:
/*
* Copyright (c) 1995 by P.J. Plauger. ALL RIGHTS RESERVED.
* Consult your license regarding permissions and restrictions.
*/
--
Alexander Terekhov
> Alexander Terekhov wrote:
>
> > You know, in my humble opinion,
>
> Ha ha ha. Humble. Ha.
Yes, that was *indeed* an attempt to produce something
sarcastic; sort of "black-humor". I'm glad that it worked.
Thanks.
> > you could earn a lot
> > more credit and respect if both of you would join and
> > demonstrate your all-around-talents ("on-topic"), in
> > these discussions:
>
> I don't think either of these gentlemen need to worry about the level of
> respect they've earned in the community.
"good" for them. ;-)
> You on the other hand, have proven yourself to be a newsgroup troll,
Nah, FWIW, I would prefer the usenet term of "Strong Opinion".
Or perhaps/even something along the lines of: (somewhere/sometime
in the cyberspace):
"I don't think Mr. XXXX is a Troll, but I do think he is
quick to draw his insult pistols."
"A lot of people, and in my opinion including Mr. YYYYY,
confuse a difference of opinion, perhaps rather a very
strong difference of opinion, as a personal slam and so
they respond in kind with comments about people's motives,
inappropriateness, and unworthiness."
etc.
But, frankly, I have NO problems with "Troll"/"PLONK"/Whatever
labels either. Everyone is entitled to have and express opinions
on the free usenet. You too. ;-)
> with a scant level of knowledge just sufficient to blather on and on,
> but without any real understanding of the subjects.
Uhhm. Interesting. Care to clarify and point out my posts
(using just ids or perhaps google links) "without any real
understanding of the subjects"?
Of course, those few/a couple of my just-4-fun anti-COPS,
anti-Troll_Allert, anti-YOU_ARE_"ABUSER" public
"contributions" here (c.l.c++) aside, please.
regards,
alexander.
Eric D Crahen
itself fits in really nicely with the boost library. I think the article
is a good kick start, especially for people just getting started with threads and
templates.
I also thought the examples were very helpful in explaining the use of
the library. Particularly the one illustrating how functors can be used as a
function pointer to create a new thread.
Since it starts out addressing the lack of a portable standard thread
library, maybe it should include a Related Work section. It's a very
notable work, but not the only one. For example, I also have a free portable
thread library (ZThreads http://zthread.sourceforge.net) that was created
for the same reasons but takes a less generic and more object oriented approach.
There is also a nice thread library included as part of the ACE communication
framework (http://www.cs.wustl.edu/~schmidt/ACE.html). These libraries are
all a little different, and have different things to offer so it might be
worth taking a look at all of them to see which might be best suited for a
project.
So, that's why CUJ wasn't intrested in the ZThreads article ;) Maybe next
year.
- Eric
http://www.cse.buffalo.edu/~crahen
Alexander Terekhov
[...]
> Particularly the one illustrating how functors can be used as a
> function pointer to create a new thread.
Yes, but why not "build-in" the binder stuff into "thread-factories",
AND provide support for return values (generic, templates) too,
AND make thread exit() work in type safe-manner too; throwing bad_cast
or something like that on at attempt to "cheat"/error? I mean
(briefly/"illustrations"):
http://groups.google.com/groups?as_umsgid=c29b5e33.0202140422.203f1141%40posting.google.com
#include <thread>
void write_message( const char* );
void thread::main()
{
new_thread( write_message,"Hello..." )->join();
new_thread( write_message,"World!!!");
}
---
#include <thread>
int my_operation( int );
class my_fancy_thread : public thread {
public:
class attr : public thread::attr {
public: /*...add some fancy stuff...*/ };
/*...add some fancy stuff...*/ };
// called by thread::attr::new_thread<> function(s)
thread* create_thread_object( const my_fancy_thread::attr& );
// overloads NOOP defaults; called in the context of NEW thread
void on_thread_start( my_fancy_thread* );
void on_thread_termination( my_fancy_thread* );
void thread::main()
{
joinable_thread_ptr< int,my_fancy_thread > pthread =
my_fancy_thread::attr().set_system_contention_scope()
.set_sched_policy( sched::FIFO )
.set_fancy_blabla()
.set_initialy_suspended( true )
.set_daemon( true ) // ders, that's for
you ;-)
.new_thread( my_operation,
some_magic_number );
/*...*/
pthread->start();
// result is stored in joinable_thread_object< result,thread_type >
// managed by smart thread ptr (thread_ptr<> and
joinable_thread_ptr<>)
int* presult = pthread->timedjoin( timeout::relative( 1000 ) );
if ( thread::timedout( presult ) &&
thread::canceled( presult = pthread->cancel().join() ) ) {
cout << "OOPS: timedout and canceled!";
}
else {
cout << "DONE: " << *presult;
}
return 0;
}
?!
> Since it starts out addressing the lack of a portable standard thread
> library, maybe it should include a Related Work section. It's a very
> notable work, but not the only one. For example, I also have a free portable
> thread library (ZThreads http://zthread.sourceforge.net) that was created
> for the same reasons but takes a less generic and more object oriented approach.
Why don't you try to explain/"sell" your alternative designs/ideas
*here*, now?
> There is also a nice thread library included as part of the ACE communication
> framework (http://www.cs.wustl.edu/~schmidt/ACE.html).
http://groups.google.com/groups?threadm=3C8FCC2F.9B4B1AAB%40web.de
(see "PACE was born to abstract support...")
regards,
alexander.
Andy Moreton
@posting.google.com>:
>Eric D Crahen <cra...@cse.buffalo.edu> wrote in message news:
<Pine.SOL.4.30.02041...@hadar.cse.Buffalo.EDU>...
>[...]
>> Particularly the one illustrating how functors can be used as a
>> function pointer to create a new thread.
>
>Yes, but why not "build-in" the binder stuff into "thread-factories",
>AND provide support for return values (generic, templates) too,
>AND make thread exit() work in type safe-manner too; throwing bad_cast
>or something like that on at attempt to "cheat"/error? I mean
>(briefly/"illustrations"):
Boost is an open minded bunch of people, who welcome contributions, and run
their own mailing lists specifically for discussion of boost issues, both for
users and for designers of boost libraries.
A few minor points:
1) The boost design is incomplete, as the docs on the boost site clearly
state. Evolution and extension of the design is expected.
2) As boost libraries are designed with an eye to possible inclusion in
future versions of the C++ standard library, a proposed thread library must
behave sensibly on all reasonably conforming implementations. Not all
platforms have pthreads, and many will never have pthreads support.
You clearly have strong opinions about the boost thread library, so why not
wander over to boost.org and contribute to the design and evolution of the
library instead of just belly-aching about it here ?
AndyM
--
GlobespanVirata, Unit 230 Science Park, Milton Road, Cambridge CB4 0WB, UK
http://www.globespanvirata.com/ Tel: +44 1223 707400 Fax: +44 1223 707447
Alexander Terekhov
Andy Moreton wrote:
>
> tere...@web.de (Alexander Terekhov) wrote in <c29b5e33.0204100621.6726b831
> @posting.google.com>:
>
> >Eric D Crahen <cra...@cse.buffalo.edu> wrote in message news:
> <Pine.SOL.4.30.02041...@hadar.cse.Buffalo.EDU>...
> >[...]
> >> Particularly the one illustrating how functors can be used as a
> >> function pointer to create a new thread.
> >
> >Yes, but why not "build-in" the binder stuff into "thread-factories",
> >AND provide support for return values (generic, templates) too,
> >AND make thread exit() work in type safe-manner too; throwing bad_cast
> >or something like that on at attempt to "cheat"/error? I mean
> >(briefly/"illustrations"):
>
> Boost is an open minded bunch of people, who welcome contributions, and run
> their own mailing lists specifically for discussion of boost issues, both for
> users and for designers of boost libraries.
I know (degree of "open mindedness"/tolerance with
respect to "Strong Opinions", CAPS, etc... ASIDE ;-)).
> A few minor points:
>
> 1) The boost design is incomplete, as the docs on the boost site clearly
> state. Evolution and extension of the design is expected.
That is NOT the point/accusation I'm loudly and rather
provocatively "crying" about all over the Net -- here,
on c.l.c++.mod, comp.std.c++, etc.
The incomplete (i.e. "BUSTED", in "Strong Opinions"
language) state of Boost.Threads affairs remains on
pretty much the same "incomplete" level since I first
joined Boost.Threads discussions (on boost.org, and
privately with Bill)... ONE YEAR PLUS A COUPLE OF WEEKS
AGO. But somehow, it was nevertheless "OK" to accept it
in the boost distribution package, present it to the
C++ committee folks and put it on the CUJ cover. Fine.
But, please, consider that my "critique" is nothing new
at all, it was all sent to the boost maillist and/or
privately to Bill long, long time ago. Well, being NOT
satisfied with the results that I was able to achieve
back then (for whatever reasons) and being unable (and
unwilling too) to try to do it "better" -- locally (on
boost), I've decided to increase the level of "Strong
Opinion" and go "public". (I have enough of spare minutes
to drop a few notes per day (or night ;-)), but such amount
of free time is NOT enough for real design and coding,
and, also, I just hate fighting compilers (and standards),
etc. doing "meta" stuff; other folks, like Dimov, have much
more skills in this domain than me-NOT-meta-lib-programmer).
That's basically the whole story (well, almost... and from
MY side only, of course ;-)).
> 2) As boost libraries are designed with an eye to possible inclusion in
> future versions of the C++ standard library, a proposed thread library must
> behave sensibly on all reasonably conforming implementations. Not all
> platforms have pthreads, and many will never have pthreads support.
Then they will NEVER have any reasonable C++ low level
threading support either. Boost.Threads IS pthreads-"spirit"
already. I just want it to be pthreads-"compliant" to a much
greater (and more is better) extent, and with much less pitfalls
then the current pure-C pthreads programming using "C-only"
pthreads-bindings lacking "managed ptrs", etc (but, again,
preserving *Pthreads/C* compatibility for the "old" threaded
code/modules).
That WAS possible to do a year ago and IS still (with
even more standard stuff added by the recent pthreads-win32
version, for example) possible NOW. But I see NO progress
(and even NO *potential* for some real progress in the "near"
future). And that is why I am "crying", copy & paste copyrighted
CUJ articles into this newsgroup and so forth... WITH a potential
to end up in Jail/become bankrupt (for (C) violation... despite
my legal insurance and that misc.legal stuff -- "who knows") and
penetrate only hell knows how many killfiles out there. I do
realize it, really (not that I care too much ;-)).
> You clearly have strong opinions about the boost thread library, so why not
> wander over to boost.org and contribute to the design and evolution of the
> library instead of just belly-aching about it here ?
Well, in addition to the "reasons" I already mentioned above,
primarily because "here" is the second best place to be (the
1st one is the Austin working group, I guess) for *Mr. Kempf*
to get some "real" advice on reasonable low level threading...
from Mr. Butenhof and others.
Unfortunately, despite a couple of my "calls"/"hints" to join
boost (w.r.t. Boost.Threads) here in the past, NOT that many
c.p.t folks actually did it, AFAIK.
regards,
alexander.
Andy Moreton
>
>Andy Moreton wrote:
>>
>> 1) The boost design is incomplete, as the docs on the boost site clearly
>> state. Evolution and extension of the design is expected.
>
>That is NOT the point/accusation I'm loudly and rather
>provocatively "crying" about all over the Net -- here,
>on c.l.c++.mod, comp.std.c++, etc.
>
>The incomplete (i.e. "BUSTED", in "Strong Opinions"
>language) state of Boost.Threads affairs remains on
>pretty much the same "incomplete" level since I first
>joined Boost.Threads discussions (on boost.org, and
>privately with Bill)... ONE YEAR PLUS A COUPLE OF WEEKS
>AGO. But somehow, it was nevertheless "OK" to accept it
>in the boost distribution package, present it to the
>C++ committee folks and put it on the CUJ cover. Fine.
So stop complaining and go write something better yourself.
>> 2) As boost libraries are designed with an eye to possible inclusion in
>> future versions of the C++ standard library, a proposed thread library
>> must behave sensibly on all reasonably conforming implementations. Not
>> all platforms have pthreads, and many will never have pthreads support.
>
>Then they will NEVER have any reasonable C++ low level
>threading support either. Boost.Threads IS pthreads-"spirit"
>already. I just want it to be pthreads-"compliant" to a much
>greater (and more is better) extent, and with much less pitfalls
>then the current pure-C pthreads programming using "C-only"
>pthreads-bindings lacking "managed ptrs", etc (but, again,
>preserving *Pthreads/C* compatibility for the "old" threaded
>code/modules).
>
>That WAS possible to do a year ago and IS still (with
>even more standard stuff added by the recent pthreads-win32
>version, for example) possible NOW. But I see NO progress
>(and even NO *potential* for some real progress in the "near"
>future).
Boost threads is not a pthreads wrapper *by design*. If what you want to see
is a set of C++ bindings to pthreads, fine - go and write it.
>> You clearly have strong opinions about the boost thread library, so why
>> not wander over to boost.org and contribute to the design and evolution
>> of the library instead of just belly-aching about it here ?
>
>Well, in addition to the "reasons" I already mentioned above,
>primarily because "here" is the second best place to be (the
>1st one is the Austin working group, I guess) for *Mr. Kempf*
>to get some "real" advice on reasonable low level threading...
>from Mr. Butenhof and others.
>
>Unfortunately, despite a couple of my "calls"/"hints" to join
>boost (w.r.t. Boost.Threads) here in the past, NOT that many
>c.p.t folks actually did it, AFAIK.
If you want code that better meets your requriements, educate yourself
sufficiently to write it. Complaining that nobody has done this for you does
not win you friends, and is tedious in the extreme.
Instead of complaining, try implementing a threading package. I'm sure that
the collective wisdom of the group would be avaialble to assist with
technical questions.
Learn to write less, think more, and edit before posting.
Alexander Terekhov
[...]
> Instead of complaining, try implementing a threading package.
http://sources.redhat.com/pthreads-win32/contributors.html
And, BTW, in Boost.Threads sources there is "still" a couple
of places in "threading package implementation" with some
stuff "coming" from me.
> I'm sure that the collective wisdom of the group would be
> avaialble to assist with technical questions.
Yes, I'm sure too. That was the whole point in "bringing"
Bill to this group.
> Learn to write less, think more, and edit before posting.
That's also always good advice. I agree.
regards,
alexander.
P.S. Now, having said all what I wanted to say about
Boost.Threads here and on other places, I'll finally
get it out of my life and completely stop "complaining".
Group, I apologize for rather "violent" and "somewhat
silly", etc. posts from me here you could have a "chance"
to read recently. The purpose was "not only" to insult
people and "troll". Hopefully, you'll understand it.
Joerg Faschingbauer
>>>>> writes:
Dragan> Well, I think that Mr. Plauger already has more than enough
Dragan> credits. If you don't know who he is, ask around.
Boah!
Dragan Cvetkovic
Sorry, I don't understand you. I do speak German, but that word is not in
my vocabulary.
Thanks.
Alwyn
Dragan Cvetkovic <d1r2a3g4a...@soli99ton.com> wrote:
> Joerg Faschingbauer <jfa...@localhost.localdomain> writes:
>
> > >>>>> "Dragan" == Dragan Cvetkovic <d1r2a3g4a...@soli99ton.com>
> > >>>>> writes:
> >
> > Dragan> Well, I think that Mr. Plauger already has more than enough
> > Dragan> credits. If you don't know who he is, ask around.
> >
> > Boah!
>
>
> Sorry, I don't understand you. I do speak German, but that word is not in
> my vocabulary.
I don't think you're missing much. :-)
Alwyn
Jonathan de Boyne Pollard
WEK> the concepts that needs a lot of work yet. I'd be interested in hearing
WEK> some of your opinions on this topic. This particular thread probably isn't
WEK> the place, [...]
Why is a discussion, in the comp.programming.threads newsgroup, in a
thread entitled ``CUJ/"The Boost.Threads Library" article -
feedback/comments?!'', not the place for feedback and comments on the
Boost.Threads library ?
Jonathan de Boyne Pollard
It was interesting to see functors used as thread functions. However, I
have some concerns over the lifetimes of the temporary objects
constructed in listing 3. I suspect that that code is not thread safe,
and that moreover the mechanism cannot be reasonably made thread safe.
It's also disappointing to see Resource Acquisition Is Initialisation
being used. This idiom encourages (even though it does not mandate) the
loss of error information, and the proliferation of programs that don't
check for errors during resource acquisition. A boost::thread::create()
function member would be a welcome addition for the benefit of those of
us who _do_ like to check for errors in our programs.
Jonathan de Boyne Pollard
AT> preference based on efficiency:
AT> boost::mutex,
AT> boost::try_mutex,
AT> boost::timed_mutex,
AT> boost::recursive_mutex,
AT> boost::recursive_try_mutex, and
AT> boost::recursive_timed_mutex.
This appears to be conflating mutex types with lock types.
Hillel Y. Sims
"Jonathan de Boyne Pollard" <J.deBoyn...@tesco.net> wrote in message
news:3CDECC9D...@tesco.net...
> It's also disappointing to see Resource Acquisition Is Initialisation
> being used. This idiom encourages (even though it does not mandate) the
> loss of error information, and the proliferation of programs that don't
> check for errors during resource acquisition.
With modern C++ designs, resource acquisition errors are represented by
throwing exceptions, so errors cannot easily be ignored or lost under this
paradigm. RAII with exceptions (combined with a compiler that really
implements threaded C++ properly), is an extremely safe and powerful
technique.
hys
--
Hillel Y. Sims
hsims AT factset.com
Alexander Terekhov
Jonathan de Boyne Pollard wrote:
>
> AT> Care to provide some "feedback"/"comments", folks?
>
> It was interesting to see functors used as thread functions. However, I
> have some concerns over the lifetimes of the temporary objects
> constructed in listing 3. I suspect that that code is not thread safe,
Why? They seem to use "copy & notify"... so, presuming
slice-free "copying" it should be "OK", I guess.
> and that moreover the mechanism cannot be reasonably made thread safe.
> It's also disappointing to see Resource Acquisition Is Initialisation
> being used. This idiom encourages (even though it does not mandate) the
> loss of error information, and the proliferation of programs that don't
> check for errors during resource acquisition. A boost::thread::create()
> function member would be a welcome addition for the benefit of those of
> us who _do_ like to check for errors in our programs.
Not sure that I understand you here... could you please elaborate?
regards,
alexander.
Daniel Miller
I agree whole-heartedly with Jonathan de Boyne Pollard. Boost.threads needs
a full airing out in the larger world outside of the Boost community. The
comp.programming.threads newsgroup is the most likely newsgroup to find
threading experts to critique Boost.threads. The Boost community has a lot of
C++ experts (although I worry that the Boost community might have a few less
wise insightful PhD sages/master-planners like the Stroustrups of the world than
I would prefer and a few more rambuncious tricksters than I would
prefer---although to be fair I have observed multiple people in the former
category within the Boost community). c.p.t has a lot of multithread experts.
The Boost.threads library is a product of the Boost communities' C++ perspective
and now needs to be critiqued heavily by thread experts outside of the Boost
community, especially if Boost.threads in its current & proposed forms is
pursuant to becoming part of the C++0x standard like Boost.threads'
proponents/authors think that Boost.threads is. (Egads!)
Another good newsgroup to air out concerns about Boost.threads becoming part
of C++0x is comp.std.c++, especially since the proponents/authors of
Boost.threads think that Boost.threads is on some manifest-destiny C++0x
standards track.
Speaking of Boost.threads being part of C++0x, I agree whole-heartedly with
Alexander Terekhov's recurring theme on multiple newsgroup-threads in multiple
newsgroups over the past months that: since there is not yet any C++ binding for
the POSIX.1 series (but there is for C, Ada, and Fortran), it would be a
tragically missed opportunity for C++0x to standardize its own reinvented
interface which does not provide POSIX (or at least the threads portions of
POSIX) with a C++ binding which IEEE & Open Group can endorse as the official
(or portion of the official) C++ binding for POSIX. [That is my wording;
Alexander's is usually "pthreads++".] My intent is for a C++ binding in POSIX
for pthreads to be some proper-subset of the eventual C++0x thread library.
C++0x may invent further extrapolations & abstractions, but IMO C++0x must
provide POSIX with a feature-complete pthreads interface, where "feature
complete" means that every feature which is in the POSIX-pthreads' C interface
is expressible somehow in the C++ binding. Obviously, this would work best if
IEEE, Open Group, and ISO/IEC/ANSI all worked jointly together as institutions
or if a sufficient critical mass of members of each standards-body/working-group
were members of the other standards-body/working-group to bring about a
sufficient amount of similarity from the grass-roots.
Jonathan de Boyne Pollard
JdeBP> It's also disappointing to see Resource Acquisition Is
JdeBP> Initialisation being used. This idiom encourages (even though
JdeBP> it does not mandate) the loss of error information, and the
JdeBP> proliferation of programs that don't check for errors during
JdeBP> resource acquisition. A boost::thread::create() function
JdeBP> member would be a welcome addition for the benefit of those of
JdeBP> us who _do_ like to check for errors in our programs.
AT> Not sure that I understand you here... could you please elaborate?
You need look no further than the AT&T "iostreams" fstream classes for an
example. They have constructors that take a filename and an open mode. But
they also have constructors that take no parameters, and a separate open()
method. (Although the design would have been better had open() returned some
form of error indicator directly rather than relying on a check of the "fail"
bit.)
Jonathan de Boyne Pollard
DM> Speaking of Boost.threads being part of C++0x, I agree
DM> whole-heartedly [...] that: since there is not yet any C++ binding
DM> for the POSIX.1 series (but there is for C, Ada, and Fortran), it
DM> would be a tragically missed opportunity for C++0x to standardize
DM> its own reinvented interface which does not provide [...] a
DM> C++ binding for POSIX.
The general consensus amongst people knowledgeable in such things,
whenever I have been present at such discussions, is that (a) the proper
place for C++ language bindings to the POSIX Threads API is the POSIX
Standard(s); and (b) given the significant differences in threading
models across operating systems, it is foolish, and does a great
disservice to applications programmers, to attempt to produce a single
API that maps on to them all.
---
[ 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 ]
Jonathan de Boyne Pollard
JdeBP> It was interesting to see functors used as thread functions.
JdeBP> However, I have some concerns over the lifetimes of the temporary
JdeBP> objects constructed in listing 3. I suspect that that code is
JdeBP> not thread safe, and that moreover the mechanism cannot be
JdeBP> reasonably made thread safe.
AT> Why? They seem to use "copy & notify"... [...]
How do you know ? Is it specified ? If it is, then this means that
application programmers have to be aware that it is not the functor
itself that is executed, but a shallow copy of it, which has
implications for the design of non-trivial applications. If it isn't,
then the library design is not guaranteed to be thread-safe.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Alexander Terekhov
Jonathan de Boyne Pollard wrote:
>
> DM> whole-heartedly [...] that: since there is not yet any C++ binding
> DM> for the POSIX.1 series (but there is for C, Ada, and Fortran), it
> DM> would be a tragically missed opportunity for C++0x to standardize
> DM> its own reinvented interface which does not provide [...] a
> DM> C++ binding for POSIX.
>
> The general consensus amongst people knowledgeable in such things,
> whenever I have been present at such discussions, is that (a) the proper
> place for C++ language bindings to the POSIX Threads API is the POSIX
> Standard(s);
Nah, the proper place for OS [threads including] C++ language
bindings is the {optional} C/C++ language bindings section(s)
in the *consolidated* C/C++/POSIX.1 *one single* 'right java'
standard. ;-)
> and (b) given the significant differences in threading
> models across operating systems, it is foolish, and does a great
> disservice to applications programmers,
Yeah... and ADA concurrency, Java/RTJ[1], Java/JSR-166[2], etc.
is just 'one example' of such "it is foolish, and does a great
disservice to applications programmers" thing, indeed. ;-) ;-)
> to attempt to produce a single API that maps on to them all.
Uhmm, I use fopen/fwrite to perform VSAM/PDS/HFS/etc. I/O...
what's wrong with such "single API that maps on to them all"?
regards,
alexander.
[1] http://www.rtj.org
[2] http://gee.cs.oswego.edu/dl/concurrency-interest/aims.html
Alexander Terekhov
Jonathan de Boyne Pollard wrote:
>
> JdeBP> However, I have some concerns over the lifetimes of the temporary
> JdeBP> objects constructed in listing 3. I suspect that that code is
> JdeBP> not thread safe, and that moreover the mechanism cannot be
> JdeBP> reasonably made thread safe.
>
> AT> Why? They seem to use "copy & notify"... [...]
>
> How do you know ? Is it specified ?
Yes. http://www.boost.org/libs/thread/doc/thread.html#class-thread
"....
thread(const boost::function0<void>& threadfunc);
Effects: Starts a new thread of execution and constructs a thread
object representing it. Copies threadfunc (which in turn copies
the function object wrapped by threadfunc) to an internal location
which persists for the lifetime of the new thread of execution.
Calls operator() on the copy of the threadfunc function object
in the new thread of execution.
...."
> If it is, then this means that
> application programmers have to be aware that it is not the functor
> itself that is executed, but a shallow copy of it,
Uhmm. 'clone' is executed, I guess. Well, it should better be
documented >>which thread<< copies threadfunc object, however.
regards,
alexander.
P.S. 'simple' thread factories e.g. 'thread_ptr p = new_thread( &void_f_void )
and joinable_thread_ptr< result,mythread > p = mythread::attr().blah( _blah_ ).
new_thread( &result_f_arg1_arg2,arg1,arg2 )' wouldn't hurt either, I guess.
William E. Kempf
>
> JdeBP> It was interesting to see functors used as thread functions.
> JdeBP> However, I have some concerns over the lifetimes of the temporary
> JdeBP> objects constructed in listing 3. I suspect that that code is
> JdeBP> not thread safe, and that moreover the mechanism cannot be
> JdeBP> reasonably made thread safe.
>
> AT> Why? They seem to use "copy & notify"... [...]
>
> How do you know ? Is it specified ?
To quote the documentation (which you could have referred to yourself):
thread(const boost::function0<void>& threadfunc);
Effects: Starts a new thread of execution and constructs a thread object
representing it. Copies threadfunc (which in turn copies the function object
wrapped by threadfunc) to an internal location which persists for the
lifetime of the new thread of execution. Calls operator() on the copy of the
threadfunc function object in the new thread of execution.
> If it is, then this means that
> application programmers have to be aware that it is not the functor
> itself that is executed, but a shallow copy of it, which has
> implications for the design of non-trivial applications.
Nothing specifies the copy has to be shallow. Other than this, I agree.
That's specifically why it's documented to be a copy. And the "implications
for the design of non-trivial applications" is not so great a burden. It's
even possible to use a wrapper that gives you pass-by-reference semantics
instead of pass-by-copy (fer instance, use boost::ref).
> If it isn't,
> then the library design is not guaranteed to be thread-safe.
The library design is certainly guaranteed to be thread-safe, even if a
wrapper is used to get pass-by-ref. What may not be thread safe is a
particular use by application code that uses pass-by-ref. This is really no
different then the void* parameter passed to pthread_create or what ever
platform specific thread creation API you want to choose. The data this
thread points at must either not be shared by multiple threads (as in, from
the moment you call the thread creation routine the data is accessed only
from the new thread), or must be properly synchronized. It's the same for
the function object used in Boost.Threads. Either only the new thread will
access the function object (and any data it carries) from the moment the
boost::thread constructor is called, or it must be properly synchronized.
Since the function object is passed-by-copy you typically won't have a need
for synchronizing anything, but if the function object carries a reference
(as is the case with the wrapper I mentioned) you may well need
synchronization here. But that's a responsibility of the application code,
not the library.
Bill Kempf