http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* pthread_create returns error code 11 - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/86e0fbae16cc43a7?hl=en
* AMD Advanced Synchronization Facility: HTM - 3 messages, 3 authors
http://groups.google.com/group/comp.programming.threads/t/c1c6c6327aed79b6?hl=en
* Why The Other Programs Don't Match Up! - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/65f54fabe8634895?hl=en
==============================================================================
TOPIC: pthread_create returns error code 11
http://groups.google.com/group/comp.programming.threads/t/86e0fbae16cc43a7?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, May 27 2009 2:44 pm
From: David Schwartz
On May 27, 2:02 pm, Harshith <harshi....@gmail.com> wrote:
> LOL because its my work :)
I don't see why that requires you to create and destroy threads rather
than reusing them.
DS
==============================================================================
TOPIC: AMD Advanced Synchronization Facility: HTM
http://groups.google.com/group/comp.programming.threads/t/c1c6c6327aed79b6?hl=en
==============================================================================
== 1 of 3 ==
Date: Thurs, May 28 2009 4:02 am
From: "Chris M. Thomasson"
"EricP" <ThatWouldBeTelling@thevillage.com> wrote in message
news:da9bd$4a119295$45c49ea8$10004@TEKSAVVY.COM...
> Chris M. Thomasson wrote:
>> "EricP" <ThatWouldBeTelling@thevillage.com> wrote in message
>>>
>>> I'm still playing with this approach, but I think a minor
>>> modification to my reader-writer lock would suffice.
>>> If a non-locked collision occurs it falls back to a
>>> FIFO ordered read-write lock.
>>
>> Interesting!
>
> I have not sorted this out yet but am still playing with it.
> But I'll toss out what I am thinking so far.
> [...]
Sounds great! One little improvement, perhaps one would use hashed locking.
Anyway, I think your on the right/correct path here.
== 2 of 3 ==
Date: Thurs, May 28 2009 7:55 am
From: "Paul A. Clayton"
On May 1, 1:26 pm, MitchAlsup <MitchAl...@aol.com> wrote:
[snip]
> Look, NOBODY is going to build their cache(s) in register technology,
> its just not dense enough. However everybody is going to have a number
> of miss buffers that ARE build in register technology. Thus if you can
> accept a reasonable limit to the number of protected liines, then the
> miss buffers are actually easy to use for this purpose.
Well, according to
http://www.anandtech.com/showdoc.aspx?i=3276&p=12
Intel's Atom L1 ICache and DCache use 8T memory cells.
And according to
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3382&p=10
Intel's Nehalem's L1 and L2 caches use 8T memory cells.
(As you mentioned, a less dense cell might be acceptable for only
tags
[and Mayan Moudgill's, I think, only applied to part of the tags].)
Paul A. Clayton
reachable as 'paaronclayton'
at "embarqmail.com"
== 3 of 3 ==
Date: Thurs, May 28 2009 7:56 am
From: EricP
Chris M. Thomasson wrote:
>
> "EricP" <ThatWouldBeTelling@thevillage.com> wrote in message
> news:da9bd$4a119295$45c49ea8$10004@TEKSAVVY.COM...
>> Chris M. Thomasson wrote:
>>> "EricP" <ThatWouldBeTelling@thevillage.com> wrote in message
>>>>
>>>> I'm still playing with this approach, but I think a minor
>>>> modification to my reader-writer lock would suffice.
>>>> If a non-locked collision occurs it falls back to a
>>>> FIFO ordered read-write lock.
>>>
>>> Interesting!
>>
>> I have not sorted this out yet but am still playing with it.
>> But I'll toss out what I am thinking so far.
>> [...]
>
> Sounds great! One little improvement, perhaps one would use hashed
> locking. Anyway, I think your on the right/correct path here.
It depends on what one thinks of blocking events vs wait loops.
One must remember that with ASF, the act of reading a memory
location during an update causes an Abort.
So contenders must go away and do something else for a while.
If going with a wait loop approach, I decided in the end that
using an atomic up-down counter to allocate delay time slots was
the best approach. Exponential back-off and retry wastes too much
time and has very bad worst case timing.
The problem with exponential delay loops is that as more nodes
are added, there is a double hit because the remote cache access
time gets longer and the N in the N**2 retry loop factor gets larger.
Worst case times can grow O(N**3).
It seems a little counter intuitive to use a memory based
counter to serialize accesses to other memory locations,
but it gives linear delay growth.
Unfortunately the details of such an approach depend on the
timing characteristics of the hardware, in particular how
long it takes to move cache lines around, and that is very
hard to find out, and is platform dependent, and highly
variable most especially depending on the node count.
The number of processors in a system can range from 2 to 64.
Larabee already has 32 processors. MS is said to be upping
the WinNT limit from 64 to 256 processors.
So worrying about large number of contenders is not unreasonable.
For NUMA systems, from what I can find, the time to access 4 cache
lines seems to range from 20ns (4 * 5ns per line) for local L2 access,
to ~100ns (4 * 25ns per hop) on a 2 processor Opteron,
to 400ns for remote L2 access on a very large system.
It is not clear how much overlap/concurrency is possible
in these operations to gather 4 cache lines.
So worrying about cache line access times of 400ns per
contender is not unreasonable.
The thing is that the cost in instructions of a delay loop
on a 3 GHz processor quickly becomes the same as an
operating system call to wait for an event.
So a non-blocking wait loops becomes harder to justify.
Eric
==============================================================================
TOPIC: Why The Other Programs Don't Match Up!
http://groups.google.com/group/comp.programming.threads/t/65f54fabe8634895?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, May 28 2009 11:14 am
From: B-Doe
Have you ever wondered why when you purchase most internet marketing
programs you never see profits? The reason is they never give you the
full package. They leave out the key ingredients to make your business
successful. Maverick's Money Making program truly is one of the best
I've ever seen. Hours of video training is included to help guide you
by almost putting you over the shoulder of a self-made millionaire. To
make the deal even better, there's even a 60 day money back guarantee!
Isn't that worth a better future for you or your family in today's
tough economy? So what are you waiting for? Visit the site below now
to change your life forever!
http://MavericksMoneyMakingNow.com - Click now while spots are still
avaliable!
==============================================================================
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