http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* An example multithreading puzzle - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/384e68160e8a32bb?hl=en
* Set processor core affinity to a thread - 2 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/4a3ea7890cf14c4f?hl=en
* What exactly is non-blocking synchronization?. - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/e470a52f60e9a599?hl=en
==============================================================================
TOPIC: An example multithreading puzzle
http://groups.google.com/group/comp.programming.threads/t/384e68160e8a32bb?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 26 2010 7:53 pm
From: "Chris M. Thomasson"
"David Schwartz" <davids@webmaster.com> wrote in message
news:50fefa04-fb77-46bb-9569-3eb555a9e6ce@b10g2000yqa.googlegroups.com...
[...]
> Don't try to assign work to specific threads or make specific threads
> do specific tasks unless there's some specific reason to do that.
> Because if you do that, you reduce the scheduler's flexibility and
> that always has a cost.
Sometimes it can be beneficial for a thread to assign work to itself which
is a "form of" assigning work to specific threads. Of course this tends to
work best if you use some sort of work-stealing scheme...
;^)
[...]
==============================================================================
TOPIC: Set processor core affinity to a thread
http://groups.google.com/group/comp.programming.threads/t/4a3ea7890cf14c4f?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Jan 27 2010 8:45 am
From: jgd@cix.compulink.co.uk
In article <__p7n.9374$Yt6.5766@newsfe23.iad>, no@spam.invalid (Chris M.
Thomasson) wrote:
> Humm... Can you please provide me with some official documentation
> that explains how `SetThreadAffinityMask()' is not reliable?
>
> BTW, are you sure that you are not writing about
> `SetThreadIdealProcessor()'? Or, perhaps are you writing about the
> fact that if processor P1 is running Thread T, and you bind the
> affinity of T to processor P1, then T will continue to run on P1
> _until_ it is rescheduled on P2?
That latter is the most obvious way you might find yourself operating
outside boundaries set by SetThreadAffinityMask().
Other possibilities include the possibility of bugs in the scheduler,
and Windows trying to keep going when the processor you set affinity to
has just died.
I'm not saying that SetThreadAffinityMask() should be considered
unreliable in general. But it's a bit of a complex thing to have the
absolute reliability required for basing a non-blocking threading design
on (which doesn't appear to be its intended purpose) in the absence of
explicit guarantees.
--
John Dallman, jgd@cix.co.uk, HTML mail is treated as probable spam.
== 2 of 2 ==
Date: Wed, Jan 27 2010 5:57 pm
From: "Chris M. Thomasson"
<jgd@cix.compulink.co.uk> wrote in message
news:rJmdnd4XC6Y_8P3WnZ2dnUVZ7t2dnZ2d@giganews.com...
> In article <__p7n.9374$Yt6.5766@newsfe23.iad>, no@spam.invalid (Chris M.
> Thomasson) wrote:
>
>> Humm... Can you please provide me with some official documentation
>> that explains how `SetThreadAffinityMask()' is not reliable?
>>
>> BTW, are you sure that you are not writing about
>> `SetThreadIdealProcessor()'? Or, perhaps are you writing about the
>> fact that if processor P1 is running Thread T, and you bind the
>> affinity of T to processor P1, then T will continue to run on P1
>> _until_ it is rescheduled on P2?
>
> That latter is the most obvious way you might find yourself operating
> outside boundaries set by SetThreadAffinityMask().
Indeed.
> Other possibilities include the possibility of bugs in the scheduler,
> and Windows trying to keep going when the processor you set affinity to
> has just died.
Ouch! :^)
> I'm not saying that SetThreadAffinityMask() should be considered
> unreliable in general. But it's a bit of a complex thing to have the
> absolute reliability required for basing a non-blocking threading design
> on (which doesn't appear to be its intended purpose)
Agreed. FWIW, there are some user-space RCU implementations that create and
bind threads to each CPU in the system (e.g., 64 CPU's would have 64
thread's). When the RCU sub-system wants to observe a synchronization epoch
it simply broadcasts a message to all of the threads and then waits for all
of them to respond. A nasty race-condition would be cast upon the RCU
implementation if one of those threads executed on a CPU other than the one
it's explicitly bound to. Yikes!
> in the absence of explicit guarantees.
I think you would need to pause the thread, set it's affinity and resume it.
The resumed thread should run on the designated processor(s). I also think
that creating a thread in a suspended state before you call
`SetThreadAffinityMask()' on it would work as well. Also, the following
paragraph in the documentation has some fairly strong language:
"Setting an affinity mask for a process or thread can result in threads
receiving less processor time, as the system is restricted from running the
threads on certain processors. In most cases, it is better to let the system
select an available processor."
The phrase:
`as the system is restricted from running the threads on certain processors'
Does seem to "imply" that the system "honors" the affinity mask. The thing
that is interesting is what happens when a processor goes offline.
:^)
==============================================================================
TOPIC: What exactly is non-blocking synchronization?.
http://groups.google.com/group/comp.programming.threads/t/e470a52f60e9a599?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Jan 27 2010 8:49 pm
From: "Chris M. Thomasson"
"persres" <persres@googlemail.com> wrote in message
news:29f7d3d3-1f36-4826-933b-1192b0cdf0db@n4g2000yqf.googlegroups.com...
> What is non-blocking synchronization?. What is lock free and wait free
> algorithm? Can someone please explain?
I would classify lock-free as having to deal with the possibility of a
failure condition that denotes forward progress "has occurred" and the
operation should be tried again (e.g., failed CAS-loop means another thread
has finished, or is successfully progressing through the algorithm.)
Wait-free basically defines true forward progress in and of itself because
there is no looping on a shared failure condition. All the threads just
progress through the algorithm at their own time. Nothing holds anything
back such that every thread can make successful progression regardless of
any other threads actions.
That is a high-level brief description of wait-free progression. It does not
deal with actual architecture concerns. For instance, an atomic
fetch-and-add operation on the x86-32/64 is loopless in software. You just
execute the instruction and the hardware does it's thing. However, on
systems with LL/SC (e.g., PPC) you have to manually build the damn
fetch-and-add instruction in software. Yes, a loop is required!
;^(...
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment