Programming With Posix Threads book
Francis Moreau
I'm planning this book but I'd like to clarify 2 points before doing
so with the help of people who already read it (I'm pretty sure most
of you in this group did ;):
1. Is there a second edition planned soon ?
2. I'm not really interested in an API description but rather in
some discussion like "why are recursive mutexes usually a bad thing",
"why is asynchronous cancel usually a bad thing" and also some
discussion about internal implementation may be interesting. Will I
find some materials in this book which address these points ?
Thanks for your feedback.
Guido Ostkamp
> I'm planning this book but I'd like to clarify 2 points before doing
> so with the help of people who already read it (I'm pretty sure most
> of you in this group did ;):
You can partially check out the book at
<http://books.google.de/books?id=_xvnuFzo7q0C&printsec=frontcover&dq=Programming+with+Posix+threads>.
Google has scanned it, and you can scroll down the pages by clicking
on the preview of the first page and use the usual keys or dragging
with the mouse. They don't have all pages, but I think it will help
you finding the answers.
Regards
Guido
Francis Moreau
bis-30-06-2...@nurfuerspam.de> wrote:
> Francis Moreau <francis.m...@gmail.com> wrote:
> > I'm planning this book but I'd like to clarify 2 points before doing
> > so with the help of people who already read it (I'm pretty sure most
> > of you in this group did ;):
>
> You can partially check out the book at
> Google has scanned it, and you can scroll down the pages by clicking
> on the preview of the first page and use the usual keys or dragging
> with the mouse.
cool, I didn't know about it.
> They don't have all pages, but I think it will help you finding the answers.
Yes except for my first point.
thanks
Francis Moreau
> > I'm planning this book but I'd like to clarify 2 points before doing
> > so with the help of people who already read it (I'm pretty sure most
> > of you in this group did ;):
>
> You can partially check out the book at
> Google has scanned it,
After looking at it, it's actually not very usefull since I have
access to a very limited content, that is a couple of pages in the
Introduction section and in section 3.2 named "Mutexes".
David Schwartz
> 2. I'm not really interested in an API description but rather in
> some discussion like "why are recursive mutexes usually a bad thing",
> "why is asynchronous cancel usually a bad thing" and also some
> discussion about internal implementation may be interesting. Will I
> find some materials in this book which address these points ?
It's not really about the philosophy of multi-threaded programming.
DS
Francis Moreau
Ok, that's sad because IMHO, it should address these points which are
FAQ I guess. BTW, I'm not sure it's about philosophy but it's rather
some interesting details that make you think about and understand some
common pitfalls.
Do you know an alternative ?
BTW, I dig into the google group archive and found some interesting
discussion about recursive mutex, see for example:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/b5cad32a77cff072/d835f2f6ef8aed99?hl=en&#d835f2f6ef8aed99
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/f9b4043864df75ba/c4f7e1b8d6ff1433?#c4f7e1b8d6ff1433
They should ring you a bell ;)
Do you know where I could get these discusions in mbox format or
whatever so I can open them up with my news reader ? (I found google
interface not really convenient, and looks like google doesn't want me
to have access to the archives otherwise than using its interface :( )
Dave Butenhof
> Hello,
>
> I'm planning this book but I'd like to clarify 2 points before doing
> so with the help of people who already read it (I'm pretty sure most
> of you in this group did ;):
>
> 1. Is there a second edition planned soon ?
I've always hoped to; but time unfortunately has never been on my side.
> 2. I'm not really interested in an API description but rather in
> some discussion like "why are recursive mutexes usually a bad thing",
> "why is asynchronous cancel usually a bad thing" and also some
> discussion about internal implementation may be interesting. Will I
> find some materials in this book which address these points ?
There's about a page of discussion on async cancel, with emphasis on why
you should avoid it, but how to use it safely in the rare cases where it
can make sense. (Async cancel unfortunately was a feature that was
enormously "watered down" from my original designs in CMA, which were
based on extensions to the VAX calling standard stack frame
representation and builtin exceptions. It would have been safe and
general; but turned out highly impractical and of course not even
remotely portable as we migrated to MIPS and then Alpha. It was probably
a mistake that we retained the minimal vestiges when that didn't work
out, and arguably more of a mistake to carry that into POSIX. That's life.)
As for recursive mutexes... this is one of the areas where the book
unfortunately shows some age. Recursive mutexes were not in POSIX until
UNIX 98 added threads and pulled in a set of common extensions. I'd
implemented recursive mutexes internally from the very beginning of my
CMA implementation (which became POSIX threads), as a tool to deal with
OS support libraries (like libc) that as yet had no thread support,
through a "global mutex" (which was implicitly recursive). [You can't
fix non-thread-safe libraries with general recursive mutexes, but only
with a single process-wide recursive mutex that everyone uses.]
Since recursive mutexes became widely available, they were eventually
formalized in POSIX. There are very few contexts where recursive mutexes
are anything remotely resembling "a good idea"; but they possess that
aura of simplicity that makes them incredibly seductive to people who
want to avoid real design. (And, in all fairness, when you can only
control the design of a part of the system, recursive mutexes may allow
a system to function that would otherwise be simply impossible. That it
might not function particularly well is in some cases a relatively minor
concern. Sometimes even legitimately minor. ;-) )
In general, my goal was to talk about the intent and usage of the POSIX
threading interface. There is a lot of commentary scattered through on
how and why, as well as why not. But it's not really a book that focuses
on "threading philosophy". (Though there's a lot mixed in.)
> Thanks for your feedback.
Francis Moreau
I wasn't hoping that the author of the book himself replied, thanks !
On Jul 23, 1:33 pm, Dave Butenhof <david.buten...@hp.com> wrote:
> Francis Moreau wrote:
> > Hello,
>
> > I'm planning this book but I'd like to clarify 2 points before doing
> > so with the help of people who already read it (I'm pretty sure most
> > of you in this group did ;):
>
> > 1. Is there a second edition planned soon ?
>
> I've always hoped to; but time unfortunately has never been on my side.
>
That's sad.
> > 2. I'm not really interested in an API description but rather in
> > some discussion like "why are recursive mutexes usually a bad thing",
> > "why is asynchronous cancel usually a bad thing" and also some
> > discussion about internal implementation may be interesting. Will I
> > find some materials in this book which address these points ?
>
> There's about a page of discussion on async cancel, with emphasis on why
> you should avoid it, but how to use it safely in the rare cases where it
> can make sense.
Ah ok, I'm interested in this kind of information.
These story details are also interesting IMHO.
It's always interesting from my point of view to understand why a
feature is part of the pthread lib and is said to be dangerous or
flawed.
And specially when they're coming from Dave Butenhof ;)
> In general, my goal was to talk about the intent and usage of the POSIX
> threading interface. There is a lot of commentary scattered through on
> how and why, as well as why not. But it's not really a book that focuses
> on "threading philosophy". (Though there's a lot mixed in.)
David Schwartz also mentioned "threading philosophy" regarding the
questions I'd like to see to be addressed in your book, but I don't
see why they're about 'philosophy'.
Dave Butenhof
> It's always interesting from my point of view to understand why a
> feature is part of the pthread lib and is said to be dangerous or
> flawed.
And there are many "off side" commentaries like this scattered through
the book; it simply wasn't my main focus.
> And specially when they're coming from Dave Butenhof ;)
>
>> In general, my goal was to talk about the intent and usage of the POSIX
>> threading interface. There is a lot of commentary scattered through on
>> how and why, as well as why not. But it's not really a book that focuses
>> on "threading philosophy". (Though there's a lot mixed in.)
>
> David Schwartz also mentioned "threading philosophy" regarding the
> questions I'd like to see to be addressed in your book, but I don't
> see why they're about 'philosophy'.
I guess I can't really see any other way to characterize exposition of
my particular biases and preferences regarding features and usage than
"philosophy".
Certainly all of these features, even asynchronous cancellation, have
valid uses. In the right circumstances, recursive mutexes can be
indispensible -- if only because in the real world you often have to
deal with poorly designed libraries you can't (or can't afford the time
to) fix. That's where we found ourselves building the first versions of
a thread library on an OS that had never supported threads, for example.
The "global (recursive) mutex" allowed us to release a library that
could be used for real work, in order to convince people that having a
thread library -- and fixing other libraries to work with it -- was a
reasonable effort.
I dislike recursive mutexes because they're usually used when a
programmer is too lazy to design a consistent scheme for internal and
external access to a facility with controlled dependencies. The result
is "thread safe" code that causes people to post notes like "I added
threads to my program and it got 3 times slower". I hate seeing those
questions, because there's usually little we can do but ask "so, um,
what did you do to make it that slow?" -- which really isn't much of a
help. ;-)
But, yeah; from my point of view, anyway, this is all "philosophy". It's
not impossible to build correct -- and even efficient -- threaded code
using recursive mutexes and asynchronous cancellation. It's just that
usually there are better ways to approach the problem.
Guido Ostkamp
> After looking at it, it's actually not very usefull since I have
> access to a very limited content, that is a couple of pages in the
> Introduction section and in section 3.2 named "Mutexes".
As I said, you can "partially" check it out. At least usually the
table of contents is fully included and some sample chapters. I don't
know whether the page range you get relies on a "search" that led to
the initial page or is fixed (I felt I got parts of chapter 2 here,
not chapter 3 like you).
Regarding the book itself:
While I found the contents very useful and I am not aware of any
better book, it turned out to be rather expensive considering the fact
that it has only 400 pages and is delivered as paperback edition (here
in Germany it is sold for ~50-67 Euro, this is about ~70-94 US $).
Regards
Guido
Antoninus Twink
> While I found the contents very useful and I am not aware of any
> better book, it turned out to be rather expensive considering the fact
> that it has only 400 pages and is delivered as paperback edition (here
> in Germany it is sold for ~50-67 Euro, this is about ~70-94 US $).
What a depressing post!
You consider it the best book on the subject, but you resent paying for
it because it is "only" 400 pages! This is exactly the warped world-view
that publishers in this area have been trying to build up, that the
correct metrics for deciding whether to buy a book are pages of length,
inches of thickness, and ounces of weight - and more is better.
This is such obvious bullshit that it's hardly worth refuting it. I'm
sure it's great for the manufacturers of bookcases, but in these days of
information overload, concision and focus will eventually win out as
desriable goals in technical writing.
Truth is, anyone can write a long book, but very few people can write a
good book.
Guido Ostkamp
> You consider it the best book on the subject, but you resent paying
> for it because it is "only" 400 pages! This is exactly the warped
> world-view that publishers in this area have been trying to build
> up, that the correct metrics for deciding whether to buy a book are
> pages of length, inches of thickness, and ounces of weight - and
> more is better.
I don't think that more content generally makes a book better.
Look at the excellent W. Richard Stevens "Unix Network Programming:
The Sockets Networking API", the price here is 55 Euro.
What do you get for it? More than 1000 pages of high quality content,
and it is a hardcover book, not just a paperback. That is excellent
value for money as it should be.
You might not like it, but yes - compared to books like the above, I
consider the "Programming With Posix Thread book" as too expensive, a
fair price would be around 35, max 40 Euro.
I believe the publishers do keep the high price because there is not
much competition around as this book's topic isn't mainstream.
And yes, I have bought it some years ago and it's still sitting on my
bookshelf along with a lot of other high quality books.
Regards
Guido
Duke Robillard
> 2. I'm not really interested in an API description but rather in
> some discussion
I recently got a book by Brian Goetz called "Java Concurrency In
Practice." It's Java-centric (no pthreads here) but it has sort
of the feel you're talking about...it's more about how to do stuff
with concurrency, rather than an API description. I've found it
really clear and easy to read.
Duke