From: Phil Carmody on
"Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
> If you [...]

Who's 'you'? Pronouns refer to prior things.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
From: Phil Carmody on
"Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
> Actually I hope that you are right and I am wrong, it would
> make my job much simpler.
>
> I also figured out how you could be mostly right, and thus
> have the superior solution

Finally you are showing your true genious!

>, this would mostly depend upon
> the details of exactly how time slicing is implemented: The
> size and frequency of each time slice. I am estimating that
> both the size and the frequency may vary over some range of
> values.
>
> My original solution might still provide slightly better
> performance for the high priority jobs, at the expense of a
> lot of trouble and potential for error, and substantial
> reduction in the performance of the other jobs.

If your other jobs might suffer from _errors_ depending on
how they're scheduled, then _you're programming them wrong_.

> The performance degradation that I might expect would be a
> small fraction of the high priority jobs might take about
> twice as long. If it is as bad as this, this would be
> acceptable. I doubt that it would be worse than this.

You're "expecting" things, and yet you've shown a complete
ignorance of how things actually are. Your expectations are
therefore basically meaningless.

Implement the simplest working solution, measure its performance,
and identify the bottlenecks. Focus on those bottlenecks, rather
than elsewhere.

Of course, the best way of making the places where there are
bottlenecks faster is by using the -funroll-loops switch.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
From: Ersek, Laszlo on
On Wed, 7 Apr 2010, Peter Olcott wrote:

> "David Schwartz" <davids(a)webmaster.com> wrote in message
> news:67a7c2a3-c7b1-4555-89c4-ae6dffe40fbc(a)r18g2000yqd.googlegroups.com...
>
>> It would be absolutely idiotic in the extreme for the kernel to delay a
>> process that attempted to 'pread' one byte from the beginning of a file
>> until a 'pwrite' to the end of that file from another process of 100MB
>> from file 'mmap'ed from a slow NFS server finished.
>
> Documentation indicates that they are atomic.

(I hope my attempt at fixing top-posting succeeded to pair matching
paragraphs.)

Fixing inaccuracies in the Linux manual pages is an ongoing activity,
AFAICT. I suggest writing a test program for the situation described
above.

lacos
From: Rainer Weikusat on
scott(a)slp53.sl.home (Scott Lurndal) writes:

[...]

> You don't get this choice. For example, the OS will take locks
> on your behalf. If you use threads, so will the standard C
> library.

A kernel running on a multiprocessor will need to use sufficient
interlocking between different entities executing kernel code in order
to provide the documented semantics of the system call
interface. Things are a little different for the C library code,
though: Since some UNIX(*) interfaces, in particular, fork, have
different semantics for single-threaded and multi-threaded processes,
the C library must not silently turn a single-threaded process into a
multi-threaded one.
From: Peter Olcott on

"Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote in
message news:87y6gye63t.fsf(a)kilospaz.fatphil.org...
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>> If you [...]
>
> Who's 'you'? Pronouns refer to prior things.
>

I can't tell who "you" is because you were so careful to
remove all of the context.

> Phil
> --
> I find the easiest thing to do is to k/f myself and just
> troll away
> -- David Melville on r.a.s.f1