Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #939 > unrolled thread

Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually

Back to article view | Back to comp.programming.threads

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 14:33 -0400
    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 11:29 +1200
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 16:27 -0400
        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 12:37 +1200
          Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 17:29 -0400
            Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 15:50 +1200
              Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 19:55 -0400
            Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-07 17:04 +0300
    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 08:16 -0400
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 05:09 -0400

#939 — Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually

On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
> On 7/6/2012 2:01 PM, Uncle Steve wrote:
> >On Sat, Jul 07, 2012 at 09:20:57AM +1200, Ian Collins wrote:
> >>On 07/ 7/12 05:08 AM, Uncle Steve wrote:
> >>>[...]
> >>>This is a concern in my mind right now as I'm writing some posix
> >>>threads code, and so obviously there are a large number of variables
> >>>which ought to be declared volatile.
> >>
> >>What leads you to that conclusion?  That line of though usually implies
> >>you are misunderstanding the relationship between volatile and threads.
> >>
> >>What are you trying to achieve with volatile?
> >
> >Well, I have some data structures that will be accessed from arbitrary
> >threads, so I want to make sure there's no funny business happening
> >behind the scenes where the compiler decides that certain accesses are
> >optional.
> 
>     Although the latest "C11" Standard adds some multi-threading
> support, I'll ignore that because (1) C11 implementations are not
> exactly thick upon the ground as yet, (2) you mentioned you're
> using Pthreads anyhow, and (3) I haven't studied the C11 threading
> stuff closely enough to be a competent commentator. ;-)
> 
>     So: As long as you're using an established non-C-specific
> threading framework, I suggest you visit comp.programming.threads,
> a newsgroup devoted to multi-threading issues.  There you will learn
> that `volatile' is neither necessary *nor* sufficient in connection
> with variables shared between threads.  (You needn't take my word on
> this: Just browse the comp.programming.threads archives and you'll
> see the local experts refuting this misunderstanding every couple
> weeks. It's comp.programming.threads' equivalent of `void main'.)
> 
>     Or, as my first threading teacher put it, "Don't Do That."

Is there are C standard threading framework?

Threaded code is a de-facto reality in today's multi-core environment.
Save for the embedded sector, most systems will run threads in
parallel, and that is that.  C has to recognize this watershed moment
in the refinement of the language.

While the specifics of an implementation within a given operating
system are not C issues, certain common optimizations can be a problem
with certain algorithms, and so there ought to be a C solution to the
problem.  What is it about the volatile attribute that makes it 
insufficient in your mind to the problem presented by threaded code?


Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [next] | [standalone]

#940

On 07/ 7/12 06:33 AM, Uncle Steve wrote:
> On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
>> On 7/6/2012 2:01 PM, Uncle Steve wrote:
>>> On Sat, Jul 07, 2012 at 09:20:57AM +1200, Ian Collins wrote:
>>>> On 07/ 7/12 05:08 AM, Uncle Steve wrote:
>>>>> [...]
>>>>> This is a concern in my mind right now as I'm writing some posix
>>>>> threads code, and so obviously there are a large number of variables
>>>>> which ought to be declared volatile.
>>>>
>>>> What leads you to that conclusion?  That line of though usually implies
>>>> you are misunderstanding the relationship between volatile and threads.
>>>>
>>>> What are you trying to achieve with volatile?
>>>
>>> Well, I have some data structures that will be accessed from arbitrary
>>> threads, so I want to make sure there's no funny business happening
>>> behind the scenes where the compiler decides that certain accesses are
>>> optional.
>>
>>      Although the latest "C11" Standard adds some multi-threading
>> support, I'll ignore that because (1) C11 implementations are not
>> exactly thick upon the ground as yet, (2) you mentioned you're
>> using Pthreads anyhow, and (3) I haven't studied the C11 threading
>> stuff closely enough to be a competent commentator. ;-)
>>
>>      So: As long as you're using an established non-C-specific
>> threading framework, I suggest you visit comp.programming.threads,
>> a newsgroup devoted to multi-threading issues.  There you will learn
>> that `volatile' is neither necessary *nor* sufficient in connection
>> with variables shared between threads.  (You needn't take my word on
>> this: Just browse the comp.programming.threads archives and you'll
>> see the local experts refuting this misunderstanding every couple
>> weeks. It's comp.programming.threads' equivalent of `void main'.)
>>
>>      Or, as my first threading teacher put it, "Don't Do That."
>
> Is there are C standard threading framework?

Yes, read C11.  If you are familiar with pthreads, you'll see where most 
of the new primitives originate.

> Threaded code is a de-facto reality in today's multi-core environment.
> Save for the embedded sector, most systems will run threads in
> parallel, and that is that.

Only if you incorporate threads in your code either explicitly or 
implicitly with something like OpenMP.

> C has to recognize this watershed moment
> in the refinement of the language.

It has.

> While the specifics of an implementation within a given operating
> system are not C issues, certain common optimizations can be a problem
> with certain algorithms, and so there ought to be a C solution to the
> problem.  What is it about the volatile attribute that makes it
> insufficient in your mind to the problem presented by threaded code?

Given you are the one going against conventional wisdom, what in your 
mind makes volatile a solution to the problem presented by threaded code?

In addition, what is "the problem presented by threaded code"?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#941

On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
> On 07/ 7/12 06:33 AM, Uncle Steve wrote:
> >On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
> >>On 7/6/2012 2:01 PM, Uncle Steve wrote:
> >>>On Sat, Jul 07, 2012 at 09:20:57AM +1200, Ian Collins wrote:
> >>>>On 07/ 7/12 05:08 AM, Uncle Steve wrote:
> >>>>>[...]
> >>>>>This is a concern in my mind right now as I'm writing some posix
> >>>>>threads code, and so obviously there are a large number of variables
> >>>>>which ought to be declared volatile.
> >>>>o
> >>>>What leads you to that conclusion?  That line of though usually implies
> >>>>you are misunderstanding the relationship between volatile and threads.
> >>>>
> >>>>What are you trying to achieve with volatile?
> >>>
> >>>Well, I have some data structures that will be accessed from arbitrary
> >>>threads, so I want to make sure there's no funny business happening
> >>>behind the scenes where the compiler decides that certain accesses are
> >>>optional.
> >>
> >>     Although the latest "C11" Standard adds some multi-threading
> >>support, I'll ignore that because (1) C11 implementations are not
> >>exactly thick upon the ground as yet, (2) you mentioned you're
> >>using Pthreads anyhow, and (3) I haven't studied the C11 threading
> >>stuff closely enough to be a competent commentator. ;-)
> >>
> >>     So: As long as you're using an established non-C-specific
> >>threading framework, I suggest you visit comp.programming.threads,
> >>a newsgroup devoted to multi-threading issues.  There you will learn
> >>that `volatile' is neither necessary *nor* sufficient in connection
> >>with variables shared between threads.  (You needn't take my word on
> >>this: Just browse the comp.programming.threads archives and you'll
> >>see the local experts refuting this misunderstanding every couple
> >>weeks. It's comp.programming.threads' equivalent of `void main'.)
> >>
> >>     Or, as my first threading teacher put it, "Don't Do That."
> >
> >Is there are C standard threading framework?
> 
> Yes, read C11.  If you are familiar with pthreads, you'll see where most 
> of the new primitives originate.

Well, I don't follow gcc development, so I don't know when those
features will be available on my system.

> >Threaded code is a de-facto reality in today's multi-core environment.
> >Save for the embedded sector, most systems will run threads in
> >parallel, and that is that.
> 
> Only if you incorporate threads in your code either explicitly or 
> implicitly with something like OpenMP.

Well, sure, but I'd like to think that multithreaded applications will
be popular.  It helps to improve the interactivity of applications
with a GUI frontend for one thing, never mind what you can do with
message-passing interfaces or asynchronus network I/O threads.
 
> >C has to recognize this watershed moment
> >in the refinement of the language.
> 
> It has.

O.K., so do nested structure elements inherit the parent structure's
volatile attribute?
 
> >While the specifics of an implementation within a given operating
> >system are not C issues, certain common optimizations can be a problem
> >with certain algorithms, and so there ought to be a C solution to the
> >problem.  What is it about the volatile attribute that makes it
> >insufficient in your mind to the problem presented by threaded code?
> 
> Given you are the one going against conventional wisdom, what in your 
> mind makes volatile a solution to the problem presented by threaded code?
>
> In addition, what is "the problem presented by threaded code"?

Well, code optimization from global CSE might eliminate memory
accesses to variable that could be modified by other threads in ways
that affect the algorithm.  Depends of the code.


Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#942

On 07/ 7/12 08:27 AM, Uncle Steve wrote:
> On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
>> On 07/ 7/12 06:33 AM, Uncle Steve wrote:
>>>
>>> Is there are C standard threading framework?
>>
>> Yes, read C11.  If you are familiar with pthreads, you'll see where most
>> of the new primitives originate.
>
> Well, I don't follow gcc development, so I don't know when those
> features will be available on my system.

Then use your platform's native threading primitives.

>>> Threaded code is a de-facto reality in today's multi-core environment.
>>> Save for the embedded sector, most systems will run threads in
>>> parallel, and that is that.
>>
>> Only if you incorporate threads in your code either explicitly or
>> implicitly with something like OpenMP.
>
> Well, sure, but I'd like to think that multithreaded applications will
> be popular.  It helps to improve the interactivity of applications
> with a GUI frontend for one thing, never mind what you can do with
> message-passing interfaces or asynchronus network I/O threads.

There already are.

>>> C has to recognize this watershed moment
>>> in the refinement of the language.
>>
>> It has.
>
> O.K., so do nested structure elements inherit the parent structure's
> volatile attribute?

A volatile T is a volatile T no matter what it contains.

>>> While the specifics of an implementation within a given operating
>>> system are not C issues, certain common optimizations can be a problem
>>> with certain algorithms, and so there ought to be a C solution to the
>>> problem.  What is it about the volatile attribute that makes it
>>> insufficient in your mind to the problem presented by threaded code?
>>
>> Given you are the one going against conventional wisdom, what in your
>> mind makes volatile a solution to the problem presented by threaded code?
>>
>> In addition, what is "the problem presented by threaded code"?
>
> Well, code optimization from global CSE might eliminate memory
> accesses to variable that could be modified by other threads in ways
> that affect the algorithm.  Depends of the code.

If the code depends on volatile, it is broken.  Use the atomics or 
synchronisation primitives provided by the language or platform.  They 
exist for a reason.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#943

On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
> On 07/ 7/12 08:27 AM, Uncle Steve wrote:
> >On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
> >>On 07/ 7/12 06:33 AM, Uncle Steve wrote:
> >>>
> >>>Is there are C standard threading framework?
> >>
> >>Yes, read C11.  If you are familiar with pthreads, you'll see where most
> >>of the new primitives originate.
> >
> >Well, I don't follow gcc development, so I don't know when those
> >features will be available on my system.
> 
> Then use your platform's native threading primitives.

Doing so would incur a performance penalty in comparison to my
synchronization primitives in some circumstances.

> >>>Threaded code is a de-facto reality in today's multi-core environment.
> >>>Save for the embedded sector, most systems will run threads in
> >>>parallelo, and that is that.
> >>
> >>Only if you incorporate threads in your code either explicitly or
> >>implicitly with something like OpenMP.
> >
> >Well, sure, but I'd like to think that multithreaded applications will
> >be popular.  It helps to improve the interactivity of applications
> >with a GUI frontend for one thing, never mind what you can do with
> >message-passing interfaces or asynchronus network I/O threads.
> 
> There already are.

Yes.  There are many examples of such code.
 
> >>>C has to recognize this watershed moment
> >>>in the refinement of the language.
> >>
> >>It has.
> >
> >O.K., so do nested structure elements inherit the parent structure's
> >volatile attribute?
> 
> A volatile T is a volatile T no matter what it contains.

Look.  In threaded applications, the truth associated with the value
associated with certain variables can be somewhat indeterminate.  If
that's true in your code, you might want to be aware of it.
 
> >>>While the specifics of an implementation within a given operating
> >>>system are not C issues, certain common optimizations can be a problem
> >>>with certain algorithms, and so there ought to be a C solution to the
> >>>problem.  What is it about the volatile attribute that makes it
> >>>insufficient in your mind to the problem presented by threaded code?
> >>
> >>Given you are the one going against conventional wisdom, what in your
> >>mind makes volatile a solution to the problem presented by threaded code?
> >>
> >>In addition, what is "the problem presented by threaded code"?
> >
> >Well, code optimization from global CSE might eliminate memory
> >accesses to variable that could be modified by other threads in ways
> >that affect the algorithm.  Depends of the code.
> 
> If the code depends on volatile, it is broken.  Use the atomics or 
> synchronisation primitives provided by the language or platform.  They 
> exist for a reason.

You aren't listening to me.



Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#944

On 07/ 7/12 09:29 AM, Uncle Steve wrote:
> On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
>> On 07/ 7/12 08:27 AM, Uncle Steve wrote:
>>> On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
>>>> On 07/ 7/12 06:33 AM, Uncle Steve wrote:
>>>>>
>>>>> Is there are C standard threading framework?
>>>>
>>>> Yes, read C11.  If you are familiar with pthreads, you'll see where most
>>>> of the new primitives originate.
>>>
>>> Well, I don't follow gcc development, so I don't know when those
>>> features will be available on my system.
>>
>> Then use your platform's native threading primitives.
>
> Doing so would incur a performance penalty in comparison to my
> synchronization primitives in some circumstances.

In other words, correctness would incur a performance penalty in 
comparison to your synchronization primitives in some circumstances.

>>> O.K., so do nested structure elements inherit the parent structure's
>>> volatile attribute?
>>
>> A volatile T is a volatile T no matter what it contains.
>
> Look.  In threaded applications, the truth associated with the value
> associated with certain variables can be somewhat indeterminate.  If
> that's true in your code, you might want to be aware of it.

If I could parse that, I'd respond to it.

>>>>> While the specifics of an implementation within a given operating
>>>>> system are not C issues, certain common optimizations can be a problem
>>>>> with certain algorithms, and so there ought to be a C solution to the
>>>>> problem.  What is it about the volatile attribute that makes it
>>>>> insufficient in your mind to the problem presented by threaded code?
>>>>
>>>> Given you are the one going against conventional wisdom, what in your
>>>> mind makes volatile a solution to the problem presented by threaded code?
>>>>
>>>> In addition, what is "the problem presented by threaded code"?
>>>
>>> Well, code optimization from global CSE might eliminate memory
>>> accesses to variable that could be modified by other threads in ways
>>> that affect the algorithm.  Depends of the code.
>>
>> If the code depends on volatile, it is broken.  Use the atomics or
>> synchronisation primitives provided by the language or platform.  They
>> exist for a reason.
>
> You aren't listening to me.

You aren't making much sense.

An example of you your synchronization primitives would clear things up.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#945

On Sat, Jul 07, 2012 at 03:50:59PM +1200, Ian Collins wrote:
> On 07/ 7/12 09:29 AM, Uncle Steve wrote:
> >On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
> >>On 07/ 7/12 08:27 AM, Uncle Steve wrote:
> >>>On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
> >>>>On 07/ 7/12 06:33 AM, Uncle Steve wrote:
> >>>>>
> >>>>>Is there are C standard threading framework?
> >>>>
> >>>>Yes, read C11.  If you are familiar with pthreads, you'll see where most
> >>>>of the new primitives originate.
> >>>
> >>>Well, I don't follow gcc development, so I don't know when those
> >>>features will be available on my system.
> >>
> >>Then use your platform's native threading primitives.
> >
> >Doing so would incur a performance penalty in comparison to my
> >synchronization primitives in some circumstances.
> 
> In other words, correctness would incur a performance penalty in 
> comparison to your synchronization primitives in some circumstances.

You probably shouldn't be using google translate to massage my code
into something you can understand.  It doesn't work like that.
 
> >>>O.K., so do nested structure elements inherit the parent structure's
> >>>volatile attribute?
> >>
> >>A volatile T is a volatile T no matter what it contains.
> >
> >Look.  In threaded applications, the truth associated with the value
> >associated with certain variables can be somewhat indeterminate.  If
> >that's true in your code, you might want to be aware of it.
> 
> If I could parse that, I'd respond to it.

Yeah well it happens.
 
> >>>>>While the specifics of an implementation within a given operating
> >>>>>system are not C issues, certain common optimizations can be a problem
> >>>>>with certain algorithms, and so there ought to be a C solution to the
> >>>>>problem.  What is it about the volatile attribute that makes it
> >>>>>insufficient in your mind to the problem presented by threaded code?
> >>>>
> >>>>Given you are the one going against conventional wisdom, what in your
> >>>>mind makes volatile a solution to the problem presented by threaded 
> >>>>code?
> >>>>
> >>>>In addition, what is "the problem presented by threaded code"?
> >>>
> >>>Well, code optimization from global CSE might eliminate memory
> >>>accesses to variable that could be modified by other threads in ways
> >>>that affect the algorithm.  Depends of the code.
> >>
> >>If the code depends on volatile, it is broken.  Use the atomics or
> >>synchronisation primitives provided by the language or platform.  They
> >>exist for a reason.
> >
> >You aren't listening to me.
> 
> You aren't making much sense.
> 
> An example of you your synchronization primitives would clear things up.

Sorry, you're going to have to wait.


Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#948

Uncle Steve <stevet810@gmail.com> writes:
> On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
> > If the code depends on volatile, it is broken.  Use the atomics or 
> > synchronisation primitives provided by the language or platform.  They 
> > exist for a reason.
> 
> You aren't listening to me.

PKB.

I think you'll find that it's not Ian who needs the assistance.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

[toc] | [prev] | [next] | [standalone]

#946

On 7/6/2012 2:33 PM, Uncle Steve wrote:
> On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
>> [...]
>>      Although the latest "C11" Standard adds some multi-threading
>> support, [...]
>>
>>      [...]I suggest you visit comp.programming.threads,
>> a newsgroup devoted to multi-threading issues.  There you will learn
>> that `volatile' is neither necessary *nor* sufficient in connection
>> with variables shared between threads.  [...]
>
> Is there are C standard threading framework?

     See above.

> Threaded code is a de-facto reality in today's multi-core environment.
> Save for the embedded sector, most systems will run threads in
> parallel, and that is that.  C has to recognize this watershed moment
> in the refinement of the language.

     See above.

> What is it about the volatile attribute that makes it
> insufficient in your mind to the problem presented by threaded code?

     "Then Kolokolo Bird said, with a mournful cry, 'Go to the banks of
the great grey-green, greasy Limpopo River -- er, that is, the G,G-G,G
comp.programming.threads newsgroup -- all set about with fever-trees,
and find out.'"

     By "go," I mean "go away," as in "Don't continue this thread in
comp.lang.c unless you specifically wish to discuss the threading
features of C11."  Follow-ups set.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#947

On Sat, Jul 07, 2012 at 08:16:53AM -0400, Eric Sosman wrote:
> On 7/6/2012 2:33 PM, Uncle Steve wrote:
> >On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
> >>[...]
> >>     Although the latest "C11" Standard adds some multi-threading
> >>support, [...]
> >>
> >>     [...]I suggest you visit comp.programming.threads,
> >>a newsgroup devoted to multi-threading issues.  There you will learn
> >>that `volatile' is neither necessary *nor* sufficient in connection
> >>with variables shared between threads.  [...]
> >
> >Is there are C standard threading framework?
> 
>     See above.
> 
> >Threaded code is a de-facto reality in today's multi-core environment.
> >Save for the embedded sector, most systems will run threads in
> >parallel, and that is that.  C has to recognize this watershed moment
> >in the refinement of the language.
> 
>     See above.
> 
> >What is it about the volatile attribute that makes it
> >insufficient in your mind to the problem presented by threaded code?
> 
>     "Then Kolokolo Bird said, with a mournful cry, 'Go to the banks of
> the great grey-green, greasy Limpopo River -- er, that is, the G,G-G,G
> comp.programming.threads newsgroup -- all set about with fever-trees,
> and find out.'"
> 
>     By "go," I mean "go away," as in "Don't continue this thread in
> comp.lang.c unless you specifically wish to discuss the threading
> features of C11."  Follow-ups set.

Your message excells as an example of myopic religious orthodoxy.  I'm
not actually suggesting that there should be changes to the standard,
so I don't quite understand why you seem so threatened.



Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web