Velocity Reviews > Ruby > MultiThreading in C++

# MultiThreading in C++

ktxn1020
Guest
Posts: n/a

 02-06-2007
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?

Guest
Posts: n/a

 02-06-2007
ktxn1020 wrote:
> 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,

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.

Avdi Grimm
Guest
Posts: n/a

 02-06-2007
On 2/6/07, ktxn1020 <(E-Mail Removed)> 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?

--
Avdi

Logan Capaldo
Guest
Posts: n/a

 02-06-2007
On Wed, Feb 07, 2007 at 06:59:41AM +0900, Francis Cianfrocca 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.
>

*applauds*

David Vallner
Guest
Posts: n/a

 02-07-2007
On Tue, 06 Feb 2007 22:59:41 +0100, Francis Cianfrocca
<(E-Mail Removed)> 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 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 Vallner

Patrick Hurley
Guest
Posts: n/a

 02-07-2007
On 2/7/07, David Vallner <(E-Mail Removed)> 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

David Vallner
Guest
Posts: n/a

 02-08-2007
On Wed, 07 Feb 2007 17:28:59 +0100, Patrick Hurley <(E-Mail Removed)>
wrote:

> On 2/7/07, David Vallner <(E-Mail Removed)> 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 Vallner