Posix "predictable scheduling" and conditions

Posix "predictable scheduling" and conditions

Post by mkbuc » Sun, 09 Mar 2008 02:34:05


What does "predictable scheduling" mean for Posix threads?

What are the downsides to non-predictable scheduling?

This question is motivated by code Stevens uses in Section 7.5 of his
Network Programming, Vol. 2. The snippet below is part of his final
producer/consume example in Figure 7.7. This code has a race if the
system schedules the "signallee" thread before the "signaller" unlocks
the mutex.

He notes this race condition in his text, but then goes on to say that
with Posix, "if predictable scheduling behavior is required, then the
mutex must be locked by the thread calling pthread_cond_wait."

Pthread_mutex_lock(&nready.mutex);
if (nready.nready == 0)
Pthread_cond_signal(&nready.cond);
nready.nready++;
Pthread_mutex_unlock(&nready.mutex);

Thanks,

m
 
 
 

Posix "predictable scheduling" and conditions

Post by mkbuc » Sun, 09 Mar 2008 02:40:32


Whoops, been answered here.

(Searching on "predictable scheduling" was much better search foo.)

Thanks,

m

 
 
 

Posix "predictable scheduling" and conditions

Post by Chris Thom » Sun, 09 Mar 2008 05:05:30


[...]

Is the last sentence a direct quote from the book? The quote as-is seems to
suggest that there are times in which you can call 'pthread_cond_wait()'
with an unlocked mutex. That's troubling because you cannot ever call
'pthread_cond_wait()' with a pointer to an unlocked mutex...
 
 
 

Posix "predictable scheduling" and conditions

Post by Szabolcs F » Sun, 09 Mar 2008 06:16:20


The last sentence is obviously wrong, however, not only his quoted
sentence but your last sentence as well. In fact, you _can_ call a
`pthread_cond_wait()' with a pointer to an unlocked mutex any time.
You should not, but you can. The compiler will not tell you anything.
Neither will you get any error code at run time. Just check it out.

Well, do not forget that C is not a multi-threaded language and
Pthread is just a library. Thus, there is no compiler support for
multi-threading issues in C.

I must stress that calling the `pthread_cond_wait()' with an unlocked
mutex is a definite bug but the guys who `collectively spent hundreds
of years (sic) on the pthread issues' somehow missed to check the
obvious things.

Yeah, multicore programming is even harder without proper language
support.

Best Regards,
Szabolcs
 
 
 

Posix "predictable scheduling" and conditions

Post by Chris Thom » Sun, 09 Mar 2008 06:37:08


Of course the compiler will not tell you anything.





PThread is NOT just a library. POSIX Threads puts restrictions on a C
compiler.





Are you serious?





Speak for yourself.
 
 
 

Posix "predictable scheduling" and conditions

Post by Chris Thom » Sun, 09 Mar 2008 07:58:04


POSIX defines a system-wide standard:

http://www.yqcomputer.com/
 
 
 

Posix "predictable scheduling" and conditions

Post by Szabolcs F » Sun, 09 Mar 2008 08:17:22


Library standard but not any language one. A big difference! That is
why there is no compiler support for it. A compiler can support the
language only.

I hope I could help.

Best Regards,
Szabolcs
 
 
 

Posix "predictable scheduling" and conditions

Post by Chris Thom » Sun, 09 Mar 2008 08:33:16


The C language does not need any more operators or keywords in order to
support POSIX threads. Also, I don't think that the upcomming C++ standard
adds any new keywords or operators to support threading.





The compiler needs to render code that will not breaking a correct
multi-threaded program. So, the POSIX standard does have an effect on the
way a C compiler actually compiles the language. It should not perform
certain optimizations in critical-sections for instance. Check this out:

http://www.yqcomputer.com/
 
 
 

Posix "predictable scheduling" and conditions

Post by Szabolcs F » Sun, 09 Mar 2008 08:59:03


It does not need any more operators or keywords if it stays to be a
sequential language. On the contrary, if you want to make secure multi-
threaded programs, you need a language that supports it. A library is
just not enough. It is not enough because on the one hand only a
language can support the thinking process and, on the other hand,
compilers cannot support library element combinations. It is because
library calls are not part of the language.


Yes, probably not. It remains a sequential programming language. So
simple it is.


Yes, the "C compiler actually compiles the language". The language
stays to be sequential. So the compiler supports a sequential
language. Is it not clear to you?


Critical section is simply not known to the compiler. In C, there is
no language means to express that you want to make a piece of code a
critical section. All you have are pthread library calls. That is why,
if you would finally try it out, you can put the `pthread_cond_wait()'
outside the _intended_ critical section. The compiler is not aware of
the misuse!

That is the point. Once upon a time there were language proposals to
incorporate the notion of the critical section into language level.
Until it is not the case, the compiler cannot check the proper use of
the critical section.

I hope I was of help, though.

Best Regards,
Szabolcs
 
 
 

Posix "predictable scheduling" and conditions

Post by Frank Cusa » Sun, 09 Mar 2008 09:21:11


Chris' sentence is correct. "Can" in this context obviously means
"can correctly". There are lots of things you "can" do in C which
are semantic errors yet the language allows it. Your nitpick, while
technically correct, doesn't add anything.


I don't see the problem (within the limitations of the language).
Within C there is no way to enforce this. Even if pthread_cond_wait()
were required to use a locked mutex (beyond the existing semantic
requirement), no guarantee can be made that it is the correct mutex.

I guess they could have defined the cv to be a struct with 2 members
(the cv itself and an associated mutex) but that assumes you will
always use the mutex only along with the cv.

You are correct, issues such as these do point out the deficiencies
in using a language like C with threads.

-frank
 
 
 

Posix "predictable scheduling" and conditions

Post by Dave Buten » Sun, 09 Mar 2008 10:00:56


OK, so you're nitpicking grammar. (And given your writing, this is
rather "bold" of you.) So, yes, shall we clarify instead that one "can"
but "must not". It violates the standard; it is a serious application
error. When one steps off a cliff, nature does not raise an error flag
and put you back safely on the ground; that doesn't mean it was a good
idea. (Nor, for that matter, that physics is not well supported by nature.)


As Chris said, Pthreads is far more than "a library", because it cannot
run on top of or as part of a "generic ISO C" or "traditional BSD/SVR
UNIX" -- it places additional stringent requirements for thread-safety
on compiler, runtime, and OS.

Still, you are correct in the implication that there are constraints and
limitations placed by the structure of the language beyond the aspects
of ISO C that POSIX could extend or "profile". Some things (e.g.,
portable lock-free/wait-free constructs) could be enabled only by
language changes.


"Pthreads" is not an implementation, or even an ABI. It's a source-level
API standard. And, no, we very definitely did not "missed[sic] to check
the obvious things". There is a specifically defined error code for
pthread_cond_wait() to report this condition IF an implementation
chooses to spend the time to detect it. (Unfortunately, POSIX/UNIX error
granularity is not exactly "overly expressive", so it's one of several
possible interpretations of EINVAL.)

Those who wanted to be sure Pthreads supported the greatest possible
runtime performance did not want the standard to be bogged down with
overhead for handholding bad programs. So detection of any error that is
strictly an avoidable application bug was intended to be optional.


Yeah, just like most anything worthwhile or useful is hard. Learning to
speak a language, read music, play piano, design user interfaces...

It's not about being easy, it's about mastering the skills.
 
 
 

Posix "predictable scheduling" and conditions

Post by Chris Thom » Sun, 09 Mar 2008 10:03:41


You can create standard, secure and correct multi-threaded programs with
PThreads and C; is that not clear to you?




[...]



Luckily, C++ is flexible enough to handle threading without changes in
syntax.






Of course.







If C is too low-level for your programming abilities, then use something
else. Try Haskell or something...
 
 
 

Posix "predictable scheduling" and conditions

Post by Greg Herli » Sun, 09 Mar 2008 10:14:03

On Mar 7, 1:16m, Szabolcs Ferenczi < XXXX@XXXXX.COM >



I would say that neither the Stevens quote nor Chris' response is
"wrong" - once the relevant context in each case has been
established.

Chris's statement - that a program "cannot" call pthread_cond_wait()
with an unlocked mutex - was clearly (if implicitly) limited to the
set of all correct programs; After all, no one is interested in
writing a program that is not correct. So Chris's statement is right:
a correct program cannot call pthread_cond_wait() with an unlocked
mutex.

For the Stevens quote, the rest of the book establishes the needed
context.Stevens assumes that the reader has in fact read more of his
book than the one sentence quoted. In particular, Stevens assumes that
the reader will remember that ptrhread_cond_wait's mutex must be
locked. So, in light of that requirement, the only possible
interpretation of the quoted sentence left to the reader is, simply,
that the locked mutex passed to pthread_cond_wait() must have been
locked by the [same] thread that calls pthread_cond_wait() [and not by
some other thread].

In other words, the issue in the Stevens quote is not whether the
mutex is locked or not - but whether the thread that locked the mutex
is the same thread that calls pthread_cond_wait().


The statement may be "obviously" wrong, but yet at the same time, it
is subtly correct.

Greg
 
 
 

Posix "predictable scheduling" and conditions

Post by Golden Cal » Sun, 09 Mar 2008 16:12:23


Second edition 14th printing says pthread_cond_signal not wait.
 
 
 

Posix "predictable scheduling" and conditions

Post by Frank Cusa » Sun, 09 Mar 2008 16:15:11


Well ... let's not get overly defensive.

While what you say is (of cousr) true, the fact remains that it IS
difficult and there are other language choices that can make it
easier. First class support for threading is, in general, an
advantage, just like first class support for objects can be an
advantage.

-frank