soft and program: comp.programming.threads - 25 new messages in 5 topics

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

comp.programming.threads@googlegroups.com

Today's topics:

* PAYPAL payment wholesale BRAND shoes,clothing,watch,handbag,jean,ugg boot,t-
shirt,jersey,eyeglass,belt,wallet and so on - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/76c4b392583d16c3?hl=en
* What exactly is non-blocking synchronization?. - 6 messages, 4 authors
http://groups.google.com/group/comp.programming.threads/t/e470a52f60e9a599?hl=en
* memory_order_acquire/release in terms of LoadStore/LoadLoad/... - 9 messages,
3 authors
http://groups.google.com/group/comp.programming.threads/t/c65d8b1eb19fcc31?hl=en
* Set processor core affinity to a thread - 8 messages, 5 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: PAYPAL payment wholesale BRAND shoes,clothing,watch,handbag,jean,ugg
boot,t-shirt,jersey,eyeglass,belt,wallet and so on
http://groups.google.com/group/comp.programming.threads/t/76c4b392583d16c3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 24 2010 8:12 am
From: honesttrade

(paypal payment)(www.honest-trade06.com) wholesale Lacoste polo t
shirt
(paypal payment)(www.honest-trade06.com) wholesale Lacoste t shirt
solid color
(paypal payment)(www.honest-trade06.com) wholesale Lacoste sweater
(paypal payment)(www.honest-trade06.com) wholesale Lacoste shirt
(paypal payment)(www.honest-trade06.com) wholesale Lacoste
(paypal payment)(www.honest-trade06.com) wholesale Ralph lauren
(paypal payment)(www.honest-trade06.com) wholesale Ralph Lauren polo
(paypal payment)(www.honest-trade06.com) wholesale Polo
(paypal payment)(www.honest-trade06.com) wholesale Ralph lauren polo
t
shirt
(paypal payment)(www.honest-trade06.com) wholesale Ralph lauren t
shirt
(paypal payment)(www.honest-trade06.com) wholesale Abercrombie &
fitch
shirt
(paypal payment)(www.honest-trade06.com) wholesale Burberry shirt
(paypal payment)(www.honest-trade06.com) wholesale Burberry t shirt
(paypal payment)(www.honest-trade06.com) wholesale NBA sports jersey

T-Shirts
(paypal payment)(www.honest-trade06.com) wholesale AFF T-shirt
(paypal payment)(www.honest-trade06.com) wholesale ARMANI T-shirt
(paypal payment)(www.honest-trade06.com) wholesale BAPE T-shirt
(paypal payment)(www.honest-trade06.com) wholesale BBC T-shirt
(paypal payment)(www.honest-trade06.com) wholesale BOSS T-shirt
(paypal payment)(www.honest-trade06.com) wholesale Burberry T-shirt
(paypal payment)(www.honest-trade06.com) wholesale CA T-shirt men's
(paypal payment)(www.honest-trade06.com) wholesale CA T-shirt women's
(paypal payment)(www.honest-trade06.com) wholesale COOGI T-shirt
(paypal payment)(www.honest-trade06.com) wholesale CRYSTAL ROCK
women's
(paypal payment)(www.honest-trade06.com) wholesale D&G T-shirt
(paypal payment)(www.honest-trade06.com) wholesale DIESEL T-shirt
(paypal payment)(www.honest-trade06.com) wholesale DSQUARED T-shirt
men's
(paypal payment)(www.honest-trade06.com) wholesale DSQUARED T-shirt
women's
(paypal payment)(www.honest-trade06.com) wholesale Eck? Unltd T-shirt
(paypal payment)(www.honest-trade06.com) wholesale ED T-shirt men's
(paypal payment)(www.honest-trade06.com) wholesale ED T-shirt
women's
(paypal payment)(www.honest-trade06.com) wholesale EVISU T-shirt
(paypal payment)(www.honest-trade06.com) wholesale GGG T-shirt
(paypal payment)(www.honest-trade06.com) wholesale G-STAR T-shirt
(paypal payment)(www.honest-trade06.com) wholesale HLST T-Shirt
(paypal payment)(www.honest-trade06.com) wholesale Lacoste T-shirt
(paypal payment)(www.honest-trade06.com) wholesale Lacoste T-shirt
women's
(paypal payment)(www.honest-trade06.com) wholesale LRG T-shirt
(paypal payment)(www.honest-trade06.com) wholesale O&L T-shirt
(paypal payment)(www.honest-trade06.com) wholesale POLO 3 T-shirt
(paypal payment)(www.honest-trade06.com) wholesale 4 T-shirt
(paypal payment)(www.honest-trade06.com) wholesale POLO 5 T-shirt
(paypal payment)(www.honest-trade06.com) wholesale POLO T-shirt men's

ARMANI,APE,BBC ,BOSS ,Burberry ,CA ,COOGI ,CRYSTAL
ROCK ,D&G ,DIESEL ,DSQUARED,DSQUAREDEck,Unltd ,ED ,EVISU ,GGG ,G-
STAR ,HLST ,Lacoste ,LRG ,O&Lm,POLO 3 ,4 ,POLO 5 ,POLO
More detail land, address:http://www.honest-trade06.com

==============================================================================
TOPIC: What exactly is non-blocking synchronization?.
http://groups.google.com/group/comp.programming.threads/t/e470a52f60e9a599?hl=en
==============================================================================

== 1 of 6 ==
Date: Mon, Jan 25 2010 12:22 am
From: persres

What is non-blocking synchronization?. What is lock free and wait free
algorithm? Can someone please explain?

== 2 of 6 ==
Date: Mon, Jan 25 2010 3:51 am
From: Anthony Williams

persres <persres@googlemail.com> writes:

> What is non-blocking synchronization?. What is lock free and wait free
> algorithm? Can someone please explain?

I posted some definitions on my blog. I hope you find them useful.

http://www.justsoftwaresolutions.co.uk/threading/non_blocking_lock_free_and_wait_free.html

Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++0x thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

== 3 of 6 ==
Date: Mon, Jan 25 2010 5:12 am
From: Dmitriy Vyukov

On Jan 25, 2:51 pm, Anthony Williams <anthony....@gmail.com> wrote:
> persres <pers...@googlemail.com> writes:
> > What is non-blocking synchronization?. What is lock free and wait free
> > algorithm? Can someone please explain?
>
> I posted some definitions on my blog. I hope you find them useful.
>
> http://www.justsoftwaresolutions.co.uk/threading/non_blocking_lock_fr...

Hi Anthony,

I am not sure about the following paragraph:
> This may then mean that the data structure is now in an inconsistent state,
> and other threads cannot perform any operations on the data structure until the operation
> is complete. These threads must then continually check the state of the data structure
> in what is called a busy-wait or spin-wait. Such waits are not blocking

Term lock-free is usually used to describe system-wide forward
progress guarantees. And if the thread is killed and left a data
structure in still inconsistent state... well, forward progress is
completely busted. What I am missing?

--
Dmitriy V'jukov

== 4 of 6 ==
Date: Mon, Jan 25 2010 5:29 am
From: Anthony Williams

Dmitriy Vyukov <dvyukov@gmail.com> writes:

> On Jan 25, 2:51 pm, Anthony Williams <anthony....@gmail.com> wrote:
>> persres <pers...@googlemail.com> writes:
>> > What is non-blocking synchronization?. What is lock free and wait free
>> > algorithm? Can someone please explain?
>>
>> I posted some definitions on my blog. I hope you find them useful.
>>
>> http://www.justsoftwaresolutions.co.uk/threading/non_blocking_lock_fr...
>
> Hi Anthony,
>
> I am not sure about the following paragraph:
>> This may then mean that the data structure is now in an inconsistent state,
>> and other threads cannot perform any operations on the data structure until the operation
>> is complete. These threads must then continually check the state of the data structure
>> in what is called a busy-wait or spin-wait. Such waits are not blocking
>
> Term lock-free is usually used to describe system-wide forward
> progress guarantees. And if the thread is killed and left a data
> structure in still inconsistent state... well, forward progress is
> completely busted. What I am missing?

Many of the algorithms that I've seen leave the data structure busted if
a thread is killed mid-way through an operation. I'd still call them
lock-free: there's no explicit locks.

I'll see if I can dig out an example.

== 5 of 6 ==
Date: Mon, Jan 25 2010 8:32 am
From: frege

On Jan 25, 8:12 am, Dmitriy Vyukov <dvyu...@gmail.com> wrote:
> I am not sure about the following paragraph:
>
> > This may then mean that the data structure is now in an inconsistent state,
> > and other threads cannot perform any operations on the data structure until the operation
> > is complete. These threads must then continually check the state of the data structure
> > in what is called a busy-wait or spin-wait. Such waits are not blocking
>
> Term lock-free is usually used to describe system-wide forward
> progress guarantees. And if the thread is killed and left a data
> structure in still inconsistent state... well, forward progress is
> completely busted. What I am missing?
>

I agree. Although I don't think of it as a thread being killed, but
while the 'winning' thread is suspended, no other thread is making
progress, so it is the same idea. ie suspended indefinitely vs killed
== same thing.

CAS-RMW-loops*** are lock-free because you *know* that if the CAS
failed and had to loop, then some other thread must have made progress
(ie updated the target address).

Spin-looks are NOT lock-free because you might be spinning while
another thread is just suspended - ie you do NOT know that someone
made progress.

At least that's how I've always interpreted it.

*** by CAS-RMW-loops, I mean those that re-read the target and
recalculate their desired value on every loop - ie atomic_increment
using CAS. A spin-loop might be a CAS-loop, but it doesn't re-read
and re-calculate - it just keeps hoping for "was 0, set to 1".

Tony

== 6 of 6 ==
Date: Mon, Jan 25 2010 10:00 am
From: Anthony Williams

Dmitriy Vyukov <dvyukov@gmail.com> writes:

Consider an SPSC queue that uses two stacks: one for pushing, one for
popping. The push stack is reversed to become the pop stack when the pop
stack is empty. If the pop thread is killed mid-reverse then you lose
all the data that has not yet been transferred. I would argue that this
is wait-free, since the push and pop threads do not have to wait for
each other, and either can make progress. However, it is not robust
against the pop thread being terminated: if you substitute a separate
wait thread then your FIFO order is hosed.

I'll think of better wording.

==============================================================================
TOPIC: memory_order_acquire/release in terms of LoadStore/LoadLoad/...
http://groups.google.com/group/comp.programming.threads/t/c65d8b1eb19fcc31?hl=en
==============================================================================

== 1 of 9 ==
Date: Mon, Jan 25 2010 8:41 am
From: frege

For C++0x (and for 'acquire' and 'release' terminology in general),
which is correct?:

A)
acquire == LoadLoad + LoadStore
release == StoreStore + LoadStore

B)
acquire == LoadLoad
release == StoreStore

ie I would say that for a general lock, we need interpretation A
(acquire on lock, release on unlock)
but for a producer/consumer queue (or Singleton init vs access) we
only need B (release on produce, acquire on consume).

If we use A for C++0x, how do I access the weaker B when that's all I
need?

Is this a c.s.c++ question?

Tony

== 2 of 9 ==
Date: Mon, Jan 25 2010 10:52 am
From: Chris Friesen

On 01/25/2010 10:41 AM, frege wrote:
> For C++0x (and for 'acquire' and 'release' terminology in general),
> which is correct?:
>
> A)
> acquire == LoadLoad + LoadStore
> release == StoreStore + LoadStore
>
> or
>
> B)
> acquire == LoadLoad
> release == StoreStore
>
> ie I would say that for a general lock, we need interpretation A
> (acquire on lock, release on unlock)
> but for a producer/consumer queue (or Singleton init vs access) we
> only need B (release on produce, acquire on consume).

I started doing some digging out of curiousity and stumbled on something
interesting. The linux kernel (which runs on many different
architectures) basically uses the equivalent of:

read (acquire): LoadLoad
write (release): StoreStore
full barrier: LoadLoad|LoadStore|StoreStore|StoreLoad

With the above definitions, a general lock construct implies a read
barrier while taking the lock and a write barrier while releasing the lock.

On the other hand, sparc on glibc uses:

The difference is interesting...I wonder why the kernel gets away
without LoadStore and StoreLoad.

Chris

== 3 of 9 ==
Date: Mon, Jan 25 2010 11:07 am
From: Chris Friesen

On 01/25/2010 12:52 PM, Chris Friesen wrote:
> The linux kernel (which runs on many different
> architectures) basically uses the equivalent of:
>
> read (acquire): LoadLoad
> write (release): StoreStore
> full barrier: LoadLoad|LoadStore|StoreStore|StoreLoad
>
> On the other hand, sparc on glibc uses:
>
> read: LoadLoad | LoadStore
> write: StoreLoad | StoreStore
> full barrier: LoadLoad|LoadStore|StoreStore|StoreLoad
>
> The difference is interesting...I wonder why the kernel gets away
> without LoadStore and StoreLoad.

That should of course be "glibc on sparc". In any case, it looks like
the arch-specific lock functions add in the missing LoadStore/StoreLoad
barriers.

Chris

== 4 of 9 ==
Date: Mon, Jan 25 2010 11:21 am
From: frege

On Jan 25, 1:52 pm, Chris Friesen <cbf...@mail.usask.ca> wrote:
>
> I started doing some digging out of curiousity and stumbled on something
> interesting. The linux kernel (which runs on many different
> architectures) basically uses the equivalent of:
>
> read (acquire): LoadLoad
> write (release): StoreStore
> full barrier: LoadLoad|LoadStore|StoreStore|StoreLoad
>
> With the above definitions, a general lock construct implies a read
> barrier while taking the lock and a write barrier while releasing the lock.
>
> On the other hand, sparc on glibc uses:
>
> read: LoadLoad | LoadStore
> write: StoreLoad | StoreStore
> full barrier: LoadLoad|LoadStore|StoreStore|StoreLoad
>
> The difference is interesting...I wonder why the kernel gets away
> without LoadStore and StoreLoad.
>
> Chris

If I'm reading some of the same docs (ie Documentation/memory-
barriers.txt) I notice that they also, separately, use the terms
'lock' and 'unlock' for a different set of barriers. Without looking
at the docs, I think those barriers had the stronger semantics.

So I'm wondering it is to some extent just conflicting use of
terminology:

A: lock = LoadLoad + LoadStore, acquire = LoadLoad
vs
B: acquire = lock = LoadLoad + LoadStore

and similar for unlock/release.

Regardless of what is "right", I'm tempted to stop using "acquire/
release" at all since I've seen enough ambiguity to make true meaning
impossible. Even amongst those explaining C++0x.

I'm thinking of instead using a variation of 'A' (above):

lock/unlock - which is very clear to anyone using locks, which
hopefully is anyone doing lock-free

producer/consumer - weaker, and all that is needed for strictly
separated producer/comsumer situations (ie where consumer only writes,
producer only reads) ie acquire/release of 'A' above.

Or rather, I *would* switch to those terms, except that C++0x is using
'acquire/release' (for lock/unlock) AND it is using 'consume' for
data-dependency handling (ie DEC Alpha).

Tony

== 5 of 9 ==
Date: Mon, Jan 25 2010 11:49 am
From: Alexander Terekhov

frege wrote:
>
> For C++0x (and for 'acquire' and 'release' terminology in general),
> which is correct?:
>
> A)
> acquire == LoadLoad + LoadStore
> release == StoreStore + LoadStore
>
> or
>
> B)
> acquire == LoadLoad
> release == StoreStore
>
> ie I would say that for a general lock, we need interpretation A
> (acquire on lock, release on unlock)
> but for a producer/consumer queue (or Singleton init vs access) we
> only need B (release on produce, acquire on consume).

memory_order_acquire/release is 'A' in C++0x.

>
> If we use A for C++0x, how do I access the weaker B when that's all I
> need?

No way in C++0x IIRC.

>
> Is this a c.s.c++ question?

This is belated (by many years) cpp-threads@decadentplace.org.uk
question.

http://www.decadentplace.org.uk/pipermail/cpp-threads/

Ah well.

http://svn.dsource.org/projects/ares/trunk/doc/ares/std/atomic.html

;-)

regards,
alexander.

== 6 of 9 ==
Date: Mon, Jan 25 2010 11:47 am
From: Chris Friesen

On 01/25/2010 01:21 PM, frege wrote:

> If I'm reading some of the same docs (ie Documentation/memory-
> barriers.txt) I notice that they also, separately, use the terms
> 'lock' and 'unlock' for a different set of barriers. Without looking
> at the docs, I think those barriers had the stronger semantics.

More accurately that document talks about LOCK and UNLOCK as families of
locking constructs which have implied barriers. These barriers are
one-way permeable, such that operations outside the critical section may
"seep" inside them. In particular, this implies that while an UNLOCK
followed by a LOCK is equivalent to a full barrier, a LOCK followed by
an UNLOCK is not.

> Regardless of what is "right", I'm tempted to stop using "acquire/
> release" at all since I've seen enough ambiguity to make true meaning
> impossible. Even amongst those explaining C++0x.

Talking about memory barriers at all is pretty much impossible except in
the context of a well defined memory model. In that specific context it
should be possible to agree on terminology.

In the larger context of this newsgroup (which is not language specific)
the challenges do become somewhat greater. However, I suspect you'll
find that the linux kernel terminology of read/write/full barriers will
be fairly well understood. If you're coding specifically for hardware
which gives finer-grained control over the barriers (sparc, for example)
then you may need to define your terms more carefully.

> lock/unlock - which is very clear to anyone using locks, which
> hopefully is anyone doing lock-free

Ah, but the barriers required by lock-free algorithms are not
necessarily exactly the same as those required by locks. See the
one-way permeability mentioned above.

Chris

== 7 of 9 ==
Date: Mon, Jan 25 2010 12:22 pm
From: frege

On Jan 25, 2:47 pm, Chris Friesen <cbf...@mail.usask.ca> wrote:
> On 01/25/2010 01:21 PM, frege wrote:
>
> > If I'm reading some of the same docs (ie Documentation/memory-
> > barriers.txt) I notice that they also, separately, use the terms
> > 'lock' and 'unlock' for a different set of barriers. Without looking
> > at the docs, I think those barriers had the stronger semantics.
>
> More accurately that document talks about LOCK and UNLOCK as families of
> locking constructs which have implied barriers. These barriers are
> one-way permeable, such that operations outside the critical section may
> "seep" inside them. In particular, this implies that while an UNLOCK
> followed by a LOCK is equivalent to a full barrier, a LOCK followed by
> an UNLOCK is not.
>
> > Regardless of what is "right", I'm tempted to stop using "acquire/
> > release" at all since I've seen enough ambiguity to make true meaning
> > impossible. Even amongst those explaining C++0x.
>
> Talking about memory barriers at all is pretty much impossible except in
> the context of a well defined memory model. In that specific context it
> should be possible to agree on terminology.
>
> In the larger context of this newsgroup (which is not language specific)
> the challenges do become somewhat greater. However, I suspect you'll
> find that the linux kernel terminology of read/write/full barriers will
> be fairly well understood. If you're coding specifically for hardware
> which gives finer-grained control over the barriers (sparc, for example)
> then you may need to define your terms more carefully.
>
> > lock/unlock - which is very clear to anyone using locks, which
> > hopefully is anyone doing lock-free
>
> Ah, but the barriers required by lock-free algorithms are not
> necessarily exactly the same as those required by locks. See the
> one-way permeability mentioned above.
>

One-way permeability is just a consequence of locking an *object*
getting implemented as a barrier - which is *between* instructions:

a = x;
lock(mutex)
b = y;
unlock(mutex)
c = z;

a,c can move inside the lock because of where the barriers end up.
The above, translated to barriers is:

a = x;
load mutex.lock // if (CAS(...)) but focus on load aspect
--- lock_barrier = loadload|loadstore ---
b=y;
---- unlock = storestore + loadstore ---
mutex.lock = 0;
c = z;

now with barriers in place, we can see that a=x can be reordered after
mutex.lock, c=z can be reordered before mutex.unlock. Yet a,c never
cross the actual memory barriers.

So they don't permeate the underlying barriers, but they do permeate
the locks at the mutex level.

> Chris

Tony

== 8 of 9 ==
Date: Mon, Jan 25 2010 2:14 pm
From: Chris Friesen

On 01/25/2010 02:22 PM, frege wrote:

> One-way permeability is just a consequence of locking an *object*
> getting implemented as a barrier - which is *between* instructions:

I disagree. One-way permeability is simply part of the definition of a
mutex. It would be just as easy to define mutexes as impermeable, but
that could result in a performance penalty.

> a = x;
> lock(mutex)
> b = y;
> unlock(mutex)
> c = z;
>
> a,c can move inside the lock because of where the barriers end up.
> The above, translated to barriers is:
>
> a = x;
> load mutex.lock // if (CAS(...)) but focus on load aspect
> --- lock_barrier = loadload|loadstore ---
> b=y;
> ---- unlock = storestore + loadstore ---
> mutex.lock = 0;
> c = z;
>
> now with barriers in place, we can see that a=x can be reordered after
> mutex.lock, c=z can be reordered before mutex.unlock. Yet a,c never
> cross the actual memory barriers.
>
> So they don't permeate the underlying barriers, but they do permeate
> the locks at the mutex level.

You've used stricter barriers than the linux kernel does. If what you
call lock_barrier is loadload, and unlock is storestore, then the write
to "a" can happen after the write to b, and the read from "z" can happen
before the read from "y" (and in fact before the write to "a").

So the question you really need to ask is whether your barriers actually
provide loadstore/storeload guarantees, or just loadload/storestore.

Chris

== 9 of 9 ==
Date: Mon, Jan 25 2010 2:59 pm
From: Chris Friesen

On 01/25/2010 01:49 PM, Alexander Terekhov wrote:
>
> frege wrote:
>>
>> For C++0x (and for 'acquire' and 'release' terminology in general),
>> which is correct?:
>>
>> A)
>> acquire == LoadLoad + LoadStore
>> release == StoreStore + LoadStore
>>
>> or
>>
>> B)
>> acquire == LoadLoad
>> release == StoreStore

> memory_order_acquire/release is 'A' in C++0x.

Can you point to a definitive statement that acquire/release do both
imply LoadStore? I'm honestly asking here, not trying to be annoying.

It's a bit difficult given the different drafts, but for instance looking at

http://bartoszmilewski.wordpress.com/2008/12/01/c-atomics-and-memory-ordering/

there is no mention of LoadStore semantics in either acquire or release.

Chris

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

== 1 of 8 ==
Date: Mon, Jan 25 2010 1:00 pm
From: persres

Hello,
Is there anyway I can set up a thread to run on a specific
processor core? say on Windows XP. (any other windows OS?).
Is there a direct API which can do this? If not is there some other
indirect way to achieve this?
Thanks

== 2 of 8 ==
Date: Mon, Jan 25 2010 1:10 pm
From: Anthony Williams

persres <persres@googlemail.com> writes:

> Is there anyway I can set up a thread to run on a specific
> processor core? say on Windows XP. (any other windows OS?).
> Is there a direct API which can do this? If not is there some other
> indirect way to achieve this?

You can use SetThreadAffinityMask to limit which CPUs or cores a thread
can run on.

http://msdn.microsoft.com/en-us/library/ms686247%28VS.85%29.aspx

== 3 of 8 ==
Date: Mon, Jan 25 2010 2:42 pm
From: persres

On 25 Jan, 21:10, Anthony Williams <anthony....@gmail.com> wrote:
> persres <pers...@googlemail.com> writes:
> > Is there anyway I can set up a thread to run on a specific
> > processor core? say on Windows XP. (any other windows OS?).
> > Is there a direct API which can do this? If not is there some other
> > indirect way to achieve this?
>
> You can use SetThreadAffinityMask to limit which CPUs or cores a thread
> can run on.
>
> http://msdn.microsoft.com/en-us/library/ms686247%28VS.85%29.aspx
>
> Anthony
> --
> Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
> just::thread C++0x thread library http://www.stdthread.co.uk
> Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
> 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Oh. Great. I thought it was only for .net, not so. Ever used this?.
The documentation says, it usually wont help. In that case, I wonder
why such a call exists. Cant think of any scenario. I was basically
wondering if we could think of a non-blocking threading design using
this call. just fancy experimentation..thats all.
Thanks

== 4 of 8 ==
Date: Mon, Jan 25 2010 2:53 pm
From: jgd@cix.compulink.co.uk

In article
<7e0b36dc-e7b4-4125-a600-dab8fb7a3cfe@e37g2000yqn.googlegroups.com>,
persres@googlemail.com (persres) wrote:

> Is there anyway I can set up a thread to run on a specific
> processor core? say on Windows XP. (any other windows OS?).

Think carefully about why you want to do this. If the software is only
ever going to run on machines that you have control of, fine.

If it's going to be run on machines belonging to other people or
organisations, that means you won't know what combinations of cores and
sockets those machines will have. How are you going to decide which core
it should run on? When you've answered that question, consider what
happens if you run several copies of the software on the same machine:
will they all pick the same core? If so, you've achieved a worse result
than letting the operating system pick cores for you. For extra credit,
consider how you might interact with other software that picks a core to
attach itself to.

Just because Windows offers a facility, that doesn't mean you should
always use it. This is an area where it's really easy to have software
achieve a worse result than leaving the decisions to the operating
system.

--
John Dallman, jgd@cix.co.uk, HTML mail is treated as probable spam.

== 5 of 8 ==
Date: Mon, Jan 25 2010 3:01 pm
From: jgd@cix.compulink.co.uk

In article
<5a27310c-7a9c-403c-ad04-2adc2118ae68@a22g2000yqc.googlegroups.com>,
persres@googlemail.com (persres) wrote:

> The documentation says, it usually wont help. In that case, I wonder
> why such a call exists. Cant think of any scenario.

One would be something that has to handle hardware interrupts that are
always generated by hardware attached to a particular processor package.
Not exactly common.

> I was basically wondering if we could think of a non-blocking threading
> design using this call.

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.

--
John Dallman, jgd@cix.co.uk, HTML mail is treated as probable spam.

== 6 of 8 ==
Date: Mon, Jan 25 2010 3:26 pm
From: persres

On 25 Jan, 23:01, j...@cix.compulink.co.uk wrote:
> In article
> <5a27310c-7a9c-403c-ad04-2adc2118a...@a22g2000yqc.googlegroups.com>,
>
> pers...@googlemail.com (persres) wrote:
> > The documentation says, it usually wont help. In that case, I wonder
> > why such a call exists. Cant think of any scenario.
>
> One would be something that has to handle hardware interrupts that are
> always generated by hardware attached to a particular processor package.
> Not exactly common.
>
> > I was basically wondering if we could think of a non-blocking threading
> > design using this call.
>
> 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.
>
> --
> John Dallman, j...@cix.co.uk, HTML mail is treated as probable spam.
Ok. Thanks. didnt know it was just a suggestion to Windows.

== 7 of 8 ==
Date: Mon, Jan 25 2010 3:41 pm
From: "Chris M. Thomasson"

<jgd@cix.compulink.co.uk> wrote in message
news:BvadnfCHpfYov8PWnZ2dnUVZ8sednZ2d@giganews.com...
> In article
> <5a27310c-7a9c-403c-ad04-2adc2118ae68@a22g2000yqc.googlegroups.com>,
> persres@googlemail.com (persres) wrote:
>
>> The documentation says, it usually wont help. In that case, I wonder
>> why such a call exists. Cant think of any scenario.
>
> One would be something that has to handle hardware interrupts that are
> always generated by hardware attached to a particular processor package.
> Not exactly common.
>
>> I was basically wondering if we could think of a non-blocking threading
>> design using this call.
>
> 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 to
processor P1, then T will continue to run on P1 _until_ it is rescheduled on
P2?

Thanks!

== 8 of 8 ==
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.

==============================================================================
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 3:23 pm
From: persres

Hello,
Most multithreading scenarios are different. I thought of
discussing an example which is highly parallel.

Consider ,
MAX = 1024*1024;
float *arr = new float [MAX];
extern char normalize1[64];

Part 1 :
Now, I need to execute this code
for(int i = 0; i < MAX; ++i)
arr[i] = arr[i] / normalize1[i % 64];

Then, Part 2
{
char modulo[64];
memzero(modulo, 64*sizeof(char));

for(int i = 0; i < MAX; ++i)
modulo[ some_slow_function(arr[i]) % 64 ]++;

// some_slow_function is really slow. So, it would be best if we dont
wait for the first part to finish.

Print_array(modulo);
}

So, how would we improve it on a quad proc machine?. This is an
example I have cooked up based on something I have been thinking
about.
From what I have seen there is a lot of ambiguity regarding
multithreading, or may be it is just me.

(Also, if someone could suggest a nice multithreading book preferably
for windows that would be helpful. It must have some examples like the
above.)

Anyways, please suggest your solutions.
My solution -
I have just two synchronization variables, an event and a critical
section object--
HANDLE AllDoneEvent;
CRITICAL_SECTION TotalThreadsdoneCS;

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).

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. Secondly is this trivial, any
optimizations or tunings possible.
What other issues would you consider?. Thanks

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

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

soft and program

Monday, January 25, 2010

comp.programming.threads - 25 new messages in 5 topics - digest

No comments:

Blog Archive

About Me