Threads Portability
Alexander
implementing the threads part?
David Butenhof
> I want to run my program under Linux and win. How should I be
> implementing the threads part?
Use POSIX threads. Stay away from signals.
LinuxThreads is "mostly POSIX"; though there are areas where it doesn't
conform to the portable standard, it's quite enough for most normal
purposes. The weaknesses come directly from the limitations of the kernel
clone() function used to create "threads"... which are actually processes,
with their own pids and signal context. LinuxThreads has an extra "manager"
thread that helps to smooth over some of the worst of the differences, but
can't fix everything. Some of the problems have already been addressed in
upcoming kernel versions, and there's work underway to get the rest.
/------------------[ 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 ]-----/
Volker Borchert
>> I want to run my program under Linux and win. How should I be
>> implementing the threads part?
> Use POSIX threads. Stay away from signals.
What about RogueWave Threads++?
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <b...@teknon.de>
Tony Gale
David Butenhof <David.B...@compaq.com> writes:
>
> LinuxThreads is "mostly POSIX"; though there are areas where it doesn't
> conform to the portable standard, it's quite enough for most normal
> purposes. The weaknesses come directly from the limitations of the kernel
> clone() function used to create "threads"... which are actually processes,
> with their own pids and signal context. LinuxThreads has an extra "manager"
> thread that helps to smooth over some of the worst of the differences, but
> can't fix everything. Some of the problems have already been addressed in
> upcoming kernel versions, and there's work underway to get the rest.
I assume you are referring to the NGPT project here. Is anyone using it
or know how reliable it currently is. I can't seem to find any info on
how POSIX compliant it actually is or comparisons to LinuxThreads or how
it performs.
Cheers
-tony
Eric D Crahen
<SHAMLESSNESS>
There is also ZThreads, a free alternative to Threads++. :)
</SHAMELESSNESS>
Serialously though, you might find it useful. And there are the ACE &
Boost thread libraries as well.
Alexander Terekhov
Eric D Crahen wrote:
>
> <SHAMLESSNESS>
> There is also ZThreads, a free alternative to Threads++. :)
http://www.cse.Buffalo.EDU/~crahen/projects/zthread/html/classZThread_1_1Condition.html
"void wait....
Wait for this Condition object to be signaled. "
Uhmm, what do you mean? Is this sort-of-MS-event?
Or is this "real" CV with *atomic* release-and-
wait semantics? Are you sure that you impl is
"correct" with respect to signal-stealing/lost
signals? How about deadlocks in your "CV" impl?
(w.r.t. "_lock" AND "predicate" locking) ....
regards,
alexander.
Eric D Crahen
> Uhmm, what do you mean? Is this sort-of-MS-event?
It's a regular condition variable.
> Or is this "real" CV with *atomic* release-and-
> wait semantics? Are you sure that you impl is
> "correct" with respect to signal-stealing/lost
> signals? How about deadlocks in your "CV" impl?
It's open source, take a look at the code if you
want to see how it works. There aren't any signal
stealing problems or deadlock problems that I am
aware of. I have not had the time to create many
good examples of the libraries use, there a few
simple ones included with the source and documentation.
The whole point of the framework was to offer an
OO thread package, which includes interruptable
blocking operation. That's thing that I feel makes
this library a bit more unique than other libraries
that were available at the time I began that project.
Its an alternative to using thread cancelation and
function pointers. If you are a more object oriented
programmer it seem a little more natural than using
a c-style function.
Also, its not meant to emulate pthreads so it may not be
to your liking; but lots of have people have found
it useful. It might not be for everyone, and there
is always room for improvement, especially with
constructive feedback (not heckling). I don't want to
get involving in trying to "sell" my ideas as you had
suggested in an earlier post. I don't feel compeled to
convince anyone of anything, I just wanted to suggest
a few options to someone looking for a cross platform thread
library. I would rather people decide what is right for
themselves.
Alexander
or C++ sorry I don't post too often)
David Butenhof
I am referring, at least in part, to kernel work done by NGPT people. But
while NGPT has done a lot of solid work that can serve as a basis for
future improvements in Linux threading (including both scalability and
POSIX conformance), NGPT "ain't it". For now stick with the default
LinuxThreads implementation.
Except, perhaps, if your principal concern is a Java app running "billions
and billions" of threads (beyond the scalability of the current
kernel-limited LinuxThreads). Then NGPT would be far preferable to the
other, strictly user-mode (and less compatible) alternatives.
David Butenhof
> David Butenhof <David.B...@compaq.com> wrote:
>
>>> I want to run my program under Linux and win. How should I be
>>> implementing the threads part?
>
>> Use POSIX threads. Stay away from signals.
>
> What about RogueWave Threads++?
Yes, there are a variety of C++ wrappers on top of POSIX threads. If you're
coding in C++, you should carefully consider them. (But there's a lot of
drek, too; you need to carefully evaluate them from both the threads and
C++ perspectives to determine whether you're getting a life raft or an
anchor.)
However, if the C++ class library isn't implemented USING the POSIX thread
library, then you're cheating yourself of concurrency and parallelism.
Alexander Terekhov
[...]
> > Or is this "real" CV with *atomic* release-and-
> > wait semantics? Are you sure that you impl is
> > "correct" with respect to signal-stealing/lost
> > signals? How about deadlocks in your "CV" impl?
>
> It's open source, take a look at the code if you
> want to see how it works.
Eric, I also wrote this: (the line you've just snipped)
>> (w.r.t. "_lock" AND "predicate" locking) ....
Both "_lock" and "predicate" come from the sources...
As for "constructive feedback (not heckling)"... it is all
here:
Just take a look at this impl which also blocks and unblocks
individual threads, maintaining waiting "queues". Please try
to compare it with your coded logic. And, BTW, please, do not
take it personal. It isn't.
Also, you may want to take a look at:
http://sources.redhat.com/pthreads-win32
If you are interested in another CV impl. based on system
provided semas (or even events; in order NOT to make the
scheduling decision; I mean thread priorities, etc..)
Well, I also have a rather simple question:
Q) Why don't you just try to USE the *existing pthread libs*
available for almost any type of "box" you could find out
there? ... just adding objects/meta/whatever stuff ON TOP
of it?!
regards,
alexander.
Eric D Crahen
> Eric, I also wrote this: (the line you've just snipped)
>
> >> (w.r.t. "_lock" AND "predicate" locking) ....
>
> Both "_lock" and "predicate" come from the sources...
I'm not sure what you are asking me here; but I'll try and
explain my Condition implementation. I'll show part of the
interface for a Condition here so there is a little bit of
context for what I'm about to try to explain.
If anyone wants to see the full documentation its at:
http://www.cse.Buffalo.EDU/~crahen/projects/zthread/html/index.html
// snippet
class Condition {
// ..
void wait(Lockable&) throw(Synchronization_Exception);
// ..
}
This is an object that acts like a condition variable.
Its semantics are very similar to a classic condition
variable (like pthreads has). So in pthreads, a very
simple example would be,
pthread_cond_t cond = //;
pthread_mutex_t lock = //;
pthread_mutex_lock(&lock);
pthread_cond_wait(&cond, &lock);
pthread_mutex_unlock(&lock);
And in ZThreads, an equivalent example would be
Condition cond;
Mutex lock;
lock.acquire();
cond.wait(lock);
lock.release();
In the both, you'd expect the lock to be held by the calling thread
until its blocked on the condition variable, and when the wait function
returns you'd expect the lock to have been reacquired. PThreads will
return error codes on errors, and ZThreads will throw exceptions.
Maybe you found my documentation was confusing in some way? From the
outside, the serialized areas are the same but the internal part of each
implementation differs.
> Well, I also have a rather simple question:
>
> Q) Why don't you just try to USE the *existing pthread libs*
> available for almost any type of "box" you could find out
> there? ... just adding objects/meta/whatever stuff ON TOP
> of it?!
Well, there were a few reasons I took at different approach to
my implementation than the creators of the thread implementation
you pointed out. I should find time to write a short design document some
day.
The main reason I wasn't just wrapping up access to a pthreads layer with
a class. I wanted to provide different behavior than pthreads. And
I wanted to provide behavior I could implement on platforms that don't
have pthreads support. I would still have conditions, mutex, etc - but
they'd need to work a little differently, this will become clearer as I
explain.
I mentioned before something about interruptable threads, this was
my solution to aborting blocking waits. I wanted the ability to
make a thread abort any wait its currently performing (on a
synchronization object) just by calling interrupt() (a member of the
Thread class); if the thread represented by that thread object was
current blocked (perhaps on a Condition as shown above) it could abort
the wait throwing an exception.
I know that there is a cancelation mechanism in pthreads for this purpose,
and that it can also interupt system calls, but I did not want to use
this. My reasoning is that I wanted to be cross platform, so I couldn't
rely on this posix only behavior; windows doesn't have the same
cancelation mechanisms. Also, I have found cancelation mechanism awkward
to use. I wanted to create something with the same effect, but more
intuitive to use (and something that would still unwind the stack correctly).
What I ended up with was something akin to a java thread. I ultimately
wanted to be able to write something like (not a practical example, but
enough to show the syntax I was after):
public class MyThread : public class Thread {
Condition cond;
Mutex lock;
public:
virtual ~MyThread() throw();
virtual void run() throw() {
try {
Guard<Mutex> g(lock);
cond.wait(lock);
// do something
} catch(Interrupted_Exception& e) {
// wait aborted
}
}
};
int main() {
MyThread t;
try {
// Start the thread
t.start();
// Stop it from blocking
t.interrupt();
// Wait for it
t.join();
} catch(Synchronization_Exception& e) { cerr << e.what() << endl; }
}
I supposed you could think of this as a kind of deferred cancelation
that takes effect at and during most blocking operations my
synchronization objects provide.
Another reason was I wanted to make a framework that was cross platform;
pthreads is very nice, but complete implementations aren't available
on every computer platform. ZThreads also isn't implemented for
every system either, but like pthreads, I have a well defined interface
that I can keep consistent and create alternate implementations later
(maybe for MacOS, or native threads for solaris, etc). Since this library
isn't closely tied to pthreads specific behavior, it didn't seem to make
sense to impose the restriction on myself that I only create an
implementation for systems supporting pthreads.
And also, I was initially using this for a windows project I wanted to
make cross platform in which I wasn't using pthreads for win32. So my
point of view at the time was somewhat different. You might have
tackled the problem from the posix side and said, ok what I can I do to
get things to act like posix to support my library. I hit this problem
from another side, and not really the side of windows. For me, I wasn't
happy with what windows provided me, and I knew my alternatives, and I
knew what I wanted. So I looked for what behavior I needed from any
arbritary thread library (behavior that any platform was likely to have)
and I started from there.
I'm just using the systems thread libraries (weather its win32 or posix)
to create threads, block threads, etc. I'm not really relying on anything
in one system that I can find in another (with pthreads I'll use a
CV to block a thread, and win32 I'll use an event - but what I'm
intrested in is blocking the thread, not the means for blocking the
thread. That's what I'm talking about what I say I'm not depending on
something that only a specific library does)
Since I decided on creating interruptable threads, that meant I had to
find a way to choose a specific thread to wake up. Most condition
variables and mutex implementations not supporting this kind of
interruptions only have to worry about being fair (they just have to wake
up a thread, not any thread in particular, just a thread). What I needed
to do was different, if a thread is interrupt()ed I have to wake up _that_
thread and have it throw an exception. Decding to make the threads
interruptable was the reason for the logic in my implementation that uses
a specific notification appraoch, rather what you see in linux threads &
win32 pthreads.
And in the end, I ended up with a nice framework that accomplished the
initial goals I had. I have what I think is a nice alternative to
cancelation mechanisms. I'm sure there are places to improve on, but so
far the library has been pretty reliable, I've been getting feedback from
people and companies for a while that have been using it who seem to like
it.
Alexander Terekhov
Eric D Crahen wrote:
>
> On 13 Apr 2002, Alexander Terekhov wrote:
>
> > Eric, I also wrote this: (the line you've just snipped)
> >
> > >> (w.r.t. "_lock" AND "predicate" locking) ....
> >
> > Both "_lock" and "predicate" come from the sources...
>
> I'm not sure what you are asking me here; but I'll try and
> explain my Condition implementation.
Thanks for the write-up, Eric. I'll reply probably Monday
on some of your points. The thing "(w.r.t. "_lock" AND
"predicate" locking)" is this (unless I'm missing something
and/or got something wrong):
Your "coming" waiters acquire TWO locks in this order:
1. predicate
2. _lock
After "wake-up", however, the order is:
1. _lock
2. predicate
To me, it looks like a deadlock. And again, sorry,
if I just got something wrong here.
regards,
alexander.
Eric D Crahen
> Your "coming" waiters acquire TWO locks in this order:
>
> 1. predicate
> 2. _lock
>
> After "wake-up", however, the order is:
>
> 1. _lock
> 2. predicate
You're right, I'll fix that. The other thing I have been
meaning to do is to create a test suite for this library.
Thanks for pointing that out.
Alexander Terekhov
Eric D Crahen wrote:
[...]
> If anyone wants to see the full documentation its at:
> http://www.cse.Buffalo.EDU/~crahen/projects/zthread/html/index.html
>
> // snippet
> class Condition {
> // ..
> void wait(Lockable&) throw(Synchronization_Exception);
> // ..
> }
>
> This is an object that acts like a condition variable.
> Its semantics are very similar to a classic condition
> variable (like pthreads has). So in pthreads, a very
> simple example would be,
>
> pthread_cond_t cond = //;
> pthread_mutex_t lock = //;
>
> pthread_mutex_lock(&lock);
> pthread_cond_wait(&cond, &lock);
How about testing the predicate in a LOOP here?
That was just one "small" reason for my "is this
MS-style-event" comment w.r.t. to your docu.
> pthread_mutex_unlock(&lock);
>
> And in ZThreads, an equivalent example would be
>
> Condition cond;
> Mutex lock;
>
> lock.acquire();
> cond.wait(lock);
> lock.release();
>
> In the both, you'd expect the lock to be held by the calling thread
> until its blocked on the condition variable, and when the wait function
> returns you'd expect the lock to have been reacquired. PThreads will
> return error codes on errors, and ZThreads will throw exceptions.
Pthread/C++ bindings (wrappers) should also throw on errors,
I think.
> Maybe you found my documentation was confusing in some way?
Yes, I did. You docu does NOT explain the key semantics and proper
usage w.r.t. testing predicate IN A LOOP. That is really important,
I believe.
> From the
> outside, the serialized areas are the same but the internal part of each
> implementation differs.
As long as the semantics are the same, no one really cares. ;-)
(performance/parallelism/etc aside ;-) ;-))
> > Well, I also have a rather simple question:
> >
> > Q) Why don't you just try to USE the *existing pthread libs*
> > available for almost any type of "box" you could find out
> > there? ... just adding objects/meta/whatever stuff ON TOP
> > of it?!
>
> Well, there were a few reasons I took at different approach to
> my implementation than the creators of the thread implementation
> you pointed out. I should find time to write a short design document some
> day.
>
> The main reason I wasn't just wrapping up access to a pthreads layer with
> a class. I wanted to provide different behavior than pthreads. And
> I wanted to provide behavior I could implement on platforms that don't
> have pthreads support. I would still have conditions, mutex, etc - but
> they'd need to work a little differently, this will become clearer as I
> explain.
>
> I mentioned before something about interruptable threads, this was
> my solution to aborting blocking waits. I wanted the ability to
> make a thread abort any wait its currently performing (on a
> synchronization object) just by calling interrupt() (a member of the
> Thread class); if the thread represented by that thread object was
> current blocked (perhaps on a Condition as shown above) it could abort
> the wait throwing an exception.
That is how CV-waits (and any other pthread cancel.point ought
to work in C++), IMHO.
> I know that there is a cancelation mechanism in pthreads for this purpose,
> and that it can also interupt system calls, but I did not want to use
> this.
Well, it isn't portable (I mean cancel via C++ exception), indeed.
But have you first tried to pursue this a that vendor to provide
THAT-ONLY reasonable and LEGAL (in C++) way to implement thread
cancel (and exit) in C++ via exceptions? Are you saying that it
just did NOT work?
> My reasoning is that I wanted to be cross platform, so I couldn't
> rely on this posix only behavior; windows doesn't have the same
> cancelation mechanisms.
pthreads-win32 does have it (even C++ exception based option);
"syscalls" and bugs (if any) aside.
> Also, I have found cancelation mechanism awkward to use.
Why?
> I wanted to create something with the same effect, but more
> intuitive to use (and something that would still unwind the stack correctly).
That is what thread cancel and exit does! (in C with its thread
cleanup handlers and in C++ with auto object destructors -- C++
"stack-unwinding", catch(...) aside for a moment).
I'm just curious, but did you also consider something along the lines
of:
http://groups.google.com/groups?threadm=3B0BA709.973337EB%40web.de
(pthread based with "interruptible" waits, sort-of ;-))
> Another reason was I wanted to make a framework that was cross platform;
> pthreads is very nice, but complete implementations aren't available
> on every computer platform.
So, why not TRY to provide/impl THEM (i.e. Pthreads), first. I mean
something like pthreads-win32 and base your nice C++ "wrappers"/add-
ons/better-bindings on that basic *POSIX thread library*/functionality/
impl?!
> ZThreads also isn't implemented for
> every system either, but like pthreads, I have a well defined interface
> that I can keep consistent and create alternate implementations later
> (maybe for MacOS,
Apple's choice w.r.t. the system low level threading IS *Pthreads*,
AFAIK.
> or native threads for solaris, etc).
Are you saying that SUN's pthreads/Solaris lib is somehow "less"
native?
> Since this library
> isn't closely tied to pthreads specific behavior, it didn't seem to make
> sense to impose the restriction on myself that I only create an
> implementation for systems supporting pthreads.
Here I disagree strongly. There is just NO any other alternative
(on such low level with mutexes, condvars, etc.) to Pthreads
programming model -- NOT invented; yet (if you like). Period.
> And also, I was initially using this for a windows project I wanted to
> make cross platform in which I wasn't using pthreads for win32.
What's the reason?
> So my
> point of view at the time was somewhat different. You might have
> tackled the problem from the posix side and said, ok what I can I do to
> get things to act like posix to support my library. I hit this problem
> from another side, and not really the side of windows. For me, I wasn't
> happy with what windows provided me, and I knew my alternatives, and I
> knew what I wanted. So I looked for what behavior I needed from any
> arbritary thread library (behavior that any platform was likely to have)
that's pthreads! ;-)
> and I started from there.
Yes, I see. I just don't think that your choice of the "right"
side to start from was really the "right" choice. IMO, it was
NOT.
> I'm just using the systems thread libraries (weather its win32 or posix)
> to create threads, block threads, etc. I'm not really relying on anything
> in one system that I can find in another (with pthreads I'll use a
> CV to block a thread, and win32 I'll use an event - but what I'm
> intrested in is blocking the thread, not the means for blocking the
> thread. That's what I'm talking about what I say I'm not depending on
> something that only a specific library does)
>
> Since I decided on creating interruptable threads, that meant I had to
> find a way to choose a specific thread to wake up. Most condition
> variables and mutex implementations not supporting this kind of
> interruptions
Mutex isn't a cancel point! See the POSIX threads Rationale on this!!
> only have to worry about being fair (they just have to wake
> up a thread, not any thread in particular, just a thread). What I needed
> to do was different, if a thread is interrupt()ed I have to wake up _that_
> thread and have it throw an exception.
Again, that's nothing special at all.
> Decding to make the threads
> interruptable was the reason for the logic in my implementation that uses
> a specific notification appraoch, rather what you see in linux threads &
> win32 pthreads.
I'm not sure what you mean here. AFAIK (the last time I've seen it)
Linux threads sucks completely with respect to C++-stack-unwinding.
It just involves undefined/illegal behavior with respect to auto-objects
in C++ using cancel/exit on Linux threads impl. And, BTW, Kaz seemed
to agree that this need to be "fixed" (he actually said that on glibc
mail list), but I am not aware of any progress in this area to date,
unfortunately.
pthreads-win32, on the other hand, DOES HAVE C++ exception based
cancel and exit (see "asides" above).
> And in the end, I ended up with a nice framework that accomplished the
> initial goals I had. I have what I think is a nice alternative to
> cancelation mechanisms.
No, I don't think so.
> I'm sure there are places to improve on, but so
> far the library has been pretty reliable, I've been getting feedback from
> people and companies for a while that have been using it who seem to like
> it.
Thank you Eric for sharing your opinions and that nice write-up.
regards,
alexander.
Eric D Crahen
> > So in pthreads, a very simple example would be,
[snip]
> > And in ZThreads, an equivalent example would be,
[snip]
> How about testing the predicate in a LOOP here?
I suppose you could; my only reason for those examples was to just
show how the Condition class paralleled the pthread_cond_wait
example.
> > > Well, I also have a rather simple question:
> > >
> > > Q) Why don't you just try to USE the *existing pthread libs*
> > > available for almost any type of "box" you could find out
> > > there? ... just adding objects/meta/whatever stuff ON TOP
> > > of it?!
> > I know that there is a cancelation mechanism in pthreads for this purpose,
> > and that it can also interupt system calls, but I did not want to use
> > this.
> Well, it isn't portable (I mean cancel via C++ exception), indeed.
> But have you first tried to pursue this a that vendor to provide
> THAT-ONLY reasonable and LEGAL (in C++) way to implement thread
> cancel (and exit) in C++ via exceptions? Are you saying that it
> just did NOT work?
Are you saying I should have written petitions to microsoft or
to insert-vendor-name-here hoping that one day I could buy another
copy? My experience has been that win32 compilers (not based on gcc and
mingwin, cygwin, etc) don't support this behavior correctly at all.
At the time I was using visual studio and borland compilers and on those
development platforms there just isn't posix cancelation.
> > Also, I have found cancelation mechanism awkward to use.
>
> Why?
Because I wanted to use a more robust object oriented interface. I'm not
just talking about a class wrapper, I wanted to have a coordinated
hierarchy of classes to work with. I'm more interested in design patterns
and object oriented program these days, so for my purposes, the c-style
interfaces provided by pthreads weren't enough on thier own for my
purposes. And I'm not saying anything at all about the quality of pthreads
or that I think it should use a higher level interface or anything like
that; I have no negative comments about pthreads. I'm saying that for what
I wanted to do, I needed something different.
> I'm just curious, but did you also consider something along the lines
> of:
>
> http://groups.google.com/groups?threadm=3B0BA709.973337EB%40web.de
> (pthread based with "interruptible" waits, sort-of ;-))
Something sort of along those lines is used. The actual implementation
I'm using is different. I would say its closer to, and more influenced by,
Cargill's Specific notification for java thread synchronization paper.
> So, why not TRY to provide/impl THEM (i.e. Pthreads), first. I mean
> something like pthreads-win32 and base your nice C++ "wrappers"/add-
> ons/better-bindings on that basic *POSIX thread library*/functionality/
> impl?!
I wasn't looking for any specific pthreads behavior, and the
pthreads-win32 project was already progessing. I was after a higher level
framework that could be built on pthreads.
> Are you saying that SUN's pthreads/Solaris lib is somehow "less"
> native?
Not at all. I'm saying that I wanted no dependance on any particular
threading library. It isn't required. To implement my library I only need
access to a few kinds of functions; and in writting a cross platform
library it makes perfect sense to decouple the interface from any specific
implementation. Its small abstraction and should the need arise, a pthread
implement (of my library) could be swapped out for an implementation that
uses any other thread library. I was just naming a couple libraries I knew
to have interfaces that didn't involve functions that started with
pthread_.
> > And also, I was initially using this for a windows project I wanted to
> > make cross platform in which I wasn't using pthreads for win32.
>
> What's the reason?
Why create a wrapper on top of a pthreads wrapper for win32 native
threads if all I needed were basic thread operations any library could
provide? Although, I do agree that life would be alot simpler if everyone
were posix compliant.
> Yes, I see. I just don't think that your choice of the "right"
> side to start from was really the "right" choice. IMO, it was
> NOT.
It's a matter of opinion. I firmly believe that there is always room for
improvement and there is always more than one way to accomplish your
goals. Unless your doing something flat out wrong, its a judgement call.
And regardless of whether you succeed or not, you can contribute your
expirence in making your attempt to help others. If you can pick out
something you feel you can improve, create a plan, create a design and get
there - then you certainly haven't done anything I think can be considered
wrong.
(I'm not saying windows is right, or my plaftorm of chioce here either;
Mainly, I do use posix compliant systems, which just seems more "right" to
me; maybe I'm condtradicting myself :) )
> > And in the end, I ended up with a nice framework that accomplished the
> > initial goals I had. I have what I think is a nice alternative to
> > cancelation mechanisms.
>
> No, I don't think so.
Aside from the fact it isn't pthreads, what do you find so distasteful
about it? I did warn you that it wasn't pthreads and that for that reason
you probably would not like it, didn't I? :)
- Eric
http://www.cse.buffalo.edu/~crahen
Eric D Crahen
ZThreads. I think this may offer a clearer explaination about interruption
than I expressed in my post.
http://www.cse.buffalo.edu/~crahen/projects/zthread/design.html
Hopefully, it will help people understand what I've done little more;
but if nothing else I'm sure it will be interesting for others to see
an approach thats a little different.
Alexander Terekhov
Eric D Crahen wrote:
[...]
> > But have you first tried to pursue this a that vendor to provide
> > THAT-ONLY reasonable and LEGAL (in C++) way to implement thread
> > cancel (and exit) in C++ via exceptions? Are you saying that it
> > just did NOT work?
>
> Are you saying I should have written petitions to microsoft or
> to insert-vendor-name-here hoping that one day I could buy another
> copy?
YES! Something along the lines of:
http://sources.redhat.com/ml/libc-alpha/2002-02/msg00110.html
http://sources.redhat.com/ml/libc-alpha/2002-02/msg00116.html
"Thanks a LOT for sharing your opinions/plans/whatever! ;-)
Perhaps you should read this:
http://groups.google.com/groups?as_umsgid=DEta8.55%241h5.204%40news.cpqcorp.net
"...I think any implementation that doesn't build
cancelation (and thread exit) on top of a pervasive
common exception infrastructure is broken to the point
of being unusable. Nevertheless, the standard doesn't
(and can't) require a correct implementation, so those
who do it wrong can get away with it as long as their
users allow them to. ..."
regards,
alexander.
Oh, Ah... P.S. Drepper, do you still need/want to
kill Stallman and associates? IF that could help
with the SUBJECT... we might arrange something
with my Russian friends. ;-) ;-)"
follow-ups:
http://sources.redhat.com/ml/libc-alpha/2002-02/msg00117.html
http://sources.redhat.com/ml/libc-alpha/2002-02/msg00122.html
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!! ;-) ;-)
Seriously, vendors SHOULD listen to their customer
concerns and customers SHOULD voice their opinions
and requests. Adopting "do-it-your-self" strategy is
a nice thing to do if you have a lot of free time and
have nothing better to do... to serve YOUR-OWN customers
(for example the product/project *I am* working for,
which has the *customer requests database* with a lot
of still open items in it, etc...)
Unless, of course, "do-it-your-self" is just the only
thing "left in the arsenal"... then it's indeed the
time to join OSS project(s) like:
http://sources.redhat.com/pthreads-win32
trying to provide the *standard* threading programming
model/API (C vs C++ bindings aside).
;-)
regards,
alexander.
Alexander Terekhov
Eric D Crahen wrote:
>
> I started to write a bit about my approach and design choices in making
> ZThreads. I think this may offer a clearer explaination about interruption
> than I expressed in my post.
>
> http://www.cse.buffalo.edu/~crahen/projects/zthread/design.html
"...The final reason is side effects. Pthreads cancelation will abort
some blocking calls as well. There is a specific set of functions that
the POSIX standard defines as cancelation points, but there is no solid
garuntee, in practice, that these functions will be the only
cancelation
points [1].
....
[1] Butenhof, D. R., "Programming with POSIX Threads", p148. 1997
Addison Wesley. "
Eric, sorry, but you are completely missing the point here
(and w.r.t. some other things in your write-up too, BTW ;-)).
FYI:
http://groups.google.com/groups?as_umsgid=hUFm8.1374%24fL6.26921%40news.cpqcorp.net
regards,
alexander.
Eric D Crahen
Alexander Terekhov
Eric D Crahen wrote:
>
> What am I missing?
Well, in addition to that link on cancel.points/guarantees,
how about this:
http://groups.google.com/groups?threadm=3CA06661.D8EBCF54%40web.de
(see the entire thread if you want/like)
this:
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_kill.html
(see "APPLICATION USAGE")
http://groups.google.com/groups?as_umsgid=v_3l7.1168%24bB1.47076%40news.cpqcorp.net
("likewise" stuff ;-))
and well, *THIS*:
http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09
;-)
regards,
alexander.
Eric D Crahen
I think you misunderstand the purpose of that article. Your focus is
strictly on posix issues. And if my focus were also narrowly fixed
specificaly and only on posix I would agree with you that cancelation
is not a problem.
However, what I am describing that document is what is involved in
creating an object-oriented abstraction for threads that doesnt depend
on any one particular low level thread library (posix or otherwise).
What I am exploring is way to create useful consistent behavior with any
low level thread library, not just posix ones.
I describe challaneges involved in using cancellation in such an
implementation because on posix system you will have to deal with
effects on non-pthread functions that act as cancelation points.
Because not all thread libraries are posix compliant, and ZThreads
is designed for use with any low level thread library, this is an
issue that must be dealt with. My intention is not to claim cancelation is
a bad idea, which I clearly point out at the begining of the article.
The entire purpose is to hide the need for such details from the user.
An object oriented plaftorm independant point of view is very different
from a c language binding, posix threads point of view. I'm not comparing
one to the other.
Also, I've gone through the article once more and clarifed some
of what I was saying (it is a work in progress).
I am well aware that your solution is to simlply live in a perfectly posix
world, so there is no need to try and argue or reenforce your stance
on that point with me. I completely understand your position on this.
To me this is like arguing there is no value to Qt because, after
all, the X Consortium has defined a standard library and every platform
should just use it. Those libraries are built on top of Xlib, windows,
mac, etc just as ZThreads is built on top of pthreads, windows threads,
etc. You can't discuss portable GUI libraries if Xlib is the library you
prefer and you just pretend that other libraries don't exist and other
plafotrm must use an emulation. That's not portability. Just claiming
posix threads are the only threads that matter and other systems must
comply. Thats also not portability, that is standardization.
I also do not claim that I have the best, the only or the right solution.
What I have is an alternative that is interesting and that many people
have found quite useful. What I would like to do is to find ways to
improve it from anyone who finds it interesting.
Alexander Terekhov
Eric D Crahen wrote:
[...]
> creating an object-oriented abstraction for threads that doesnt depend
> on any one particular low level thread library (posix or otherwise).
(google is lagging a bit ;-))
Newsgroups: comp.std.c++
Subject: Re: C++ and threads (invariant issues, actually)
John Nagle wrote:
[...]
> C++ really does need language-level thread
> support, because there are so many language-level
> thread issues, of which this is only one. Yes,
> you can do everything with OS calls, but the
> language isn't giving you any help in getting it
> right. Are there any good designs for this being
> proposed?
FYI:
http://groups.google.com/groups?as_umsgid=3CA9EDE3.2227EE4A%40web.de
"....
The next step could be that "full"/higher level concurrency
support via the language constructs incorporating the ideas
the Butenhof is talking about (AFAICT) from things like Ada
and perhaps some "research" works (not so widely popular,
"robust", etc) -- uC++:
ftp://plg.uwaterloo.ca/pub/uSystem
and these two papers[1]:
ftp://ftp.dsg.cs.tcd.ie/pub/doc/dsg-86.ps.gz
(Ciaran McHale, Synchronisation in Concurrent,
Object-oriented Languages: Expressive Power,
Genericity and Inheritance, 1994)
http://www.doc.ic.ac.uk/~sjg/thesis-mybg.ps.gz
(Michael Ya'akov Ben-Gershon, An Object-Oriented
Approach to Concurrency and Synchronisation, 2000)
....
[1] Just in case you will have some problems with
the links above (reportedly do NOT always
work), I've got PDFs on my site too:
http://www.terekhov.de/OO-Concurrence/dsg-86.pdf
(McHale's paper)
http://www.terekhov.de/OO-Concurrence/thesis-mybg.pdf
(Ben-Gershon's paper)
Please let me know if that's somehow
"illegal" and I'll just pull these
PDFs from my site away, immediately."
regards,
alexander.