Tuesday, January 26, 2010

comp.programming.threads - 4 new messages in 2 topics - digest

comp.programming.threads
http://groups.google.com/group/comp.programming.threads?hl=en

comp.programming.threads@googlegroups.com

Today's topics:

* Set processor core affinity to a thread - 3 messages, 3 authors
http://groups.google.com/group/comp.programming.threads/t/4a3ea7890cf14c4f?hl=en
* An example multithreading puzzle - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/384e68160e8a32bb?hl=en

==============================================================================
TOPIC: Set processor core affinity to a thread
http://groups.google.com/group/comp.programming.threads/t/4a3ea7890cf14c4f?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 25 2010 7:31 pm
From: David Schwartz


On Jan 25, 3:41 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:

> 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?

It is my understanding that if you call SetThreadAffinityMask and
disallow the current processor, the call will not return until the
thread has been rescheduled.

DS


== 2 of 3 ==
Date: Mon, Jan 25 2010 11:14 pm
From: "Chris M. Thomasson"


"David Schwartz" <davids@webmaster.com> wrote in message
news:ddacd63d-f5b2-471b-a3f3-843faf56c1f7@c34g2000yqn.googlegroups.com...
On Jan 25, 3:41 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:

> > 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,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That should be P2.


> then T will continue to run on P1 _until_ it is rescheduled on
> > P2?

> It is my understanding that if you call SetThreadAffinityMask and
> disallow the current processor, the call will not return until the
> thread has been rescheduled.

Yikes! I think I misread the following paragraph:

"If the new thread affinity mask does not specify the processor that is
currently running the thread, the thread is rescheduled on one of the
allowable processors."


in the document:


http://msdn.microsoft.com/en-us/library/ms686247(VS.85).aspx


However, it does not really clarify if the rescheduling occurs _before_ the
actual function returns.


Humm...

== 3 of 3 ==
Date: Mon, Jan 25 2010 9:12 pm
From: Jonathan de Boyne Pollard




Danger lies there. Windows does not absolutely guarantee that
if you have affinity set, you will only ever execute on that core. If
the scheduler feels it has to run you on another one, it will.

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 toprocessor P1, then T
will continue to run on P1 until it is rescheduled on P2?

It is my understanding that if you call SetThreadAffinityMask()
and disallow the current processor, the call will not return until the
thread has been rescheduled.


Your understanding is certainly in agreement with the Microsoft
documentation, referenced earlier in this discussion thread.  (-:

==============================================================================
TOPIC: An example multithreading puzzle
http://groups.google.com/group/comp.programming.threads/t/384e68160e8a32bb?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:38 pm
From: David Schwartz


On Jan 25, 3:23 pm, persres <pers...@googlemail.com> wrote:

> I have four threads. Two of them will take half each of the first
> part. After they are done they will update a simple variable
> Thread1done=1 (similarly Thread2done=2).
> Two more will take half each of the second part. After they are done,
> they will update simple variables Thread3Done=1 (similarly
> Thread4done=1).

I think you are trying to do the scheduler's job. What if one half,
for whatever reason, actually takes up taking a lot longer than the
other half? For example, some CPUs have cores that share cache. What
if one thread gets a core that's sharing a cache with a busy core and
one gets a core that's sharing a cache with a non-busy core? One
thread may finish all its work really fast and then the other half is
being finished on only one core.

You should let whatever thread happens to be running take some of
whatever work happens to be left to do, if possible. In this case,
that's very possible. So why not do it?

> Each thread will also do the following at the end of its task -
> EnterCriticalSection(TotalThreadsdoneCS);
> TotalThreadsdone++;
> if (TotalThreadsdone == 4) SetEvent(AllDoneEvent);
> ExitCriticalSection(TotalThreadsdoneCS);
>
> First of all will this work.

That should work. But what is the purpose of this event? If there's
something that needs to be done when all the work is done, WHY NOT
JUST DO IT?! Why signal an event that tells some other thread to do it
when this thread is already running and has nothing else to do?!

> Secondly is this trivial, any
> optimizations or tunings possible.
> What other issues would you consider?. Thanks

It will work, and in most cases it will even work well (because in
most cases, it pretty much doesn't matter how well you do it). Unless
you are really pushing the limits, getting synchronization well is not
really all that important so long as it is correct. But you are doing
things in a very brute force way.

DS


==============================================================================

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: