The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] C Threading
@ 2018-06-29 16:27 ron
  2018-06-29 16:59 ` Warner Losh
  0 siblings, 1 reply; 2+ messages in thread
From: ron @ 2018-06-29 16:27 UTC (permalink / raw)
  To: 'TUHS main list'

Thread local storage and starting threads up is largely a rather
inconsequential implementation detail.   When it comes down to actual
parallel programming, of which I have done more than a little, the big thing
is thread synchronization.    It's rather hardware dependent.    You can
pretty much entirely wipe out any parallism gains with a synchronization
call that results in a context switch or even a serious cache impact.    On
one side you have machines like the Denelcor HEP where every memory word had
a pair of semaphores on it and the instructions could stall the process
while waiting for them and the hardware would schedule the other threads.
On the other hand you have your x86, which you can do a few clever things
with some atomic operations and inlined assembler but a lot of the
"standard" (boost, pthread, etc...) synchs will kill you.



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [TUHS] C Threading
  2018-06-29 16:27 [TUHS] C Threading ron
@ 2018-06-29 16:59 ` Warner Losh
  0 siblings, 0 replies; 2+ messages in thread
From: Warner Losh @ 2018-06-29 16:59 UTC (permalink / raw)
  To: Ronald Natalie; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Fri, Jun 29, 2018 at 10:27 AM, <ron@ronnatalie.com> wrote:

> Thread local storage and starting threads up is largely a rather
> inconsequential implementation detail.   When it comes down to actual
> parallel programming, of which I have done more than a little, the big
> thing
> is thread synchronization.    It's rather hardware dependent.    You can
> pretty much entirely wipe out any parallism gains with a synchronization
> call that results in a context switch or even a serious cache impact.    On
> one side you have machines like the Denelcor HEP where every memory word
> had
> a pair of semaphores on it and the instructions could stall the process
> while waiting for them and the hardware would schedule the other threads.
> On the other hand you have your x86, which you can do a few clever things
> with some atomic operations and inlined assembler but a lot of the
> "standard" (boost, pthread, etc...) synchs will kill you.
>

C11 also defines thread APIs and atomic operations sufficient to do many
types of locking. POSIX layers on threads as well that could be implemented
using those atomics.

Warner

[-- Attachment #2: Type: text/html, Size: 1526 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-06-29 16:59 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-29 16:27 [TUHS] C Threading ron
2018-06-29 16:59 ` Warner Losh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).