MultiThreading in C++


#1

Hi,

I am pretty new to multithreaded programming. I have a question with a
hope someone can help me out.

I want to find distances between points using thread (Win MFC)

For instance distance from:
p1 to p2, p3, p4, p5
p2 to p1, p3, p4, p5
p3 to p1, p2, p4, p5
p4 to p1, p2, p3, p5
p5 to p1, p2, p3, p4

with

p1(x1, y1) = p1(42.67,73.75)
p2(x2, y2) = p2 (61.22, 149.9)
p3(x3, y3) = p3(30.27, 97.73)
p4(x4, y4) = p4(35.18,101.83)
p5(x5, y5) = p5(41.15, 104.87)

using formular distance = square root (square (x2 - x1) + square (y2 -
y1))

How can I do it and what is the best way to do this?

Thanks in advance,


#2

The best way to solve this problem is not to use threads. It’s
local-compute
and local-memory bound so there is no capturable system latency. The
problem
appears to be parallelizable to some degree. If you are sure you’ll be
running it on multi-processor or multicore hardware, then break up the
dataset into multiple chunks, and run each one through a separate
process.
Threads add nothing here.


#3

ktxn1020 wrote:

p3 to p1, p2, p4, p5

using formular distance = square root (square (x2 - x1) + square (y2

  • y1))

How can I do it and what is the best way to do this?

Thanks in advance,

The best way is to do your school assignments yourself ;-), you will
benefit from it in the future the great deal. Besides, it may be the
wrong list as Ruby is discussed here.

Gennady.


#4

On 2/6/07, ktxn1020 removed_email_address@domain.invalid wrote:

Hi,

I am pretty new to multithreaded programming. I have a question with a
hope someone can help me out.

First, this is a mailing list for the Ruby programming language, not
C++. You would probably have better luck on a mailing list devoted to
C++ programming, or on the comp.lang.c++ newsgroup.

Second, why are on earth are you using threads to solve the problem you
stated?


#5

On Tue, 06 Feb 2007 22:59:41 +0100, Francis C.
removed_email_address@domain.invalid wrote:

If you are sure you’ll be
running it on multi-processor or multicore hardware, then break up the
dataset into multiple chunks, and run each one through a separate
process.
Threads add nothing here.

Threads for a single process only get scheduled on one of the cores?
This
is new to me, I thought at least on Windowsen, threads are the base
scheduling unit.

David V.


#6

On Wed, Feb 07, 2007 at 06:59:41AM +0900, Francis C. wrote:

The best way to solve this problem is not to use threads. It’s local-compute
and local-memory bound so there is no capturable system latency. The problem
appears to be parallelizable to some degree. If you are sure you’ll be
running it on multi-processor or multicore hardware, then break up the
dataset into multiple chunks, and run each one through a separate process.
Threads add nothing here.

applauds


#7

On Wed, 07 Feb 2007 17:28:59 +0100, Patrick H. removed_email_address@domain.invalid
wrote:

On 2/7/07, David V. removed_email_address@domain.invalid wrote:

Threads for a single process only get scheduled on one of the cores?
This
is new to me, I thought at least on Windowsen, threads are the base
scheduling unit.

Difference between a Windows (native) thread and a Ruby (green)
thread. The Ruby interpreter does not (yet) support native threads.

The whole thread is horribly off-topic with C++ and MFC being involved
from the beginning from someone who thought ruby-talk is there to work
out
his homework. So the threads in my (equally off-topic) question are in
fact native Win32 threads.

David V.


#8

On 2/8/07, David V. removed_email_address@domain.invalid wrote:

On Wed, 07 Feb 2007 17:28:59 +0100, Patrick H. removed_email_address@domain.invalid
wrote:

On 2/7/07, David V. removed_email_address@domain.invalid wrote:

Threads for a single process only get scheduled on one of the cores?
This
is new to me, I thought at least on Windowsen, threads are the base
scheduling unit.

Horribly offtopic reply: on Windows, the scheduling unit is what Windows
calls a “thread” (and might be more properly termed a kernel thread or a
light-weight process). Essentially the same deal on Linux. On Solaris
it’s
different, you have both LWPs and userland threads. To your point,
windows
threads within a process will get scheduled on multiple cores and/or
processors (you can even tune their affinity for particular cores), but
this
adds nothing of value in the OP’s homework assignment. Partition the
incoming dataset, schedule on multiple processes, and aggregate the
result
sets at the end. So much easier to debug than a threaded implementation.


#9

On 2/7/07, David V. removed_email_address@domain.invalid wrote:

Threads for a single process only get scheduled on one of the cores? This
is new to me, I thought at least on Windowsen, threads are the base
scheduling unit.

Difference between a Windows (native) thread and a Ruby (green)
thread. The Ruby interpreter does not (yet) support native threads.

pth