[concurrency-interest] Multi-core testing, help with findings

Bjorn Antonsson ban at bea.com
Tue Dec 12 03:33:14 EST 2006


Hi,

I would say that a lot of the extra time it takes comes from the fact that the volatile stores/loads in the Worker class, actually 1000000 of them, do mean something on a multi CPU.

On a typical x86 SMP machine the load/store/load pattern on volatiles results in an mfence instruction, which is quite costly. This is a normal load/store/load without mfence on a single CPU machine, since we are guaranteed that the next thread will have the same view of the memory.

/Björn 

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu 
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf 
> Of David Harrigan
> Sent: den 12 december 2006 07:57
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Multi-core testing, help 
> with findings
> 
> Hi,
> 
> I completely forgot to mention that platform is Linux (Ubuntu 6.10).
> 
> Just scanning thru the mail, will read when I get to work...
> 
> -=david=-
> 
> 
> On 12/12/06, Gregg Wonderly <gregg at cytetech.com> wrote:
> 
> 
> 
> 	David Holmes wrote:
> 	> I've assumed the platform is Windows, but if it is 
> linux then that opens
> 	> other possibilities. The problem can be explained if 
> the busy-wait thread
> 	> doesn't get descheduled (which is easy to test by 
> changing it to not be a 
> 	> busy-wait). The issue as to why it doesn't get 
> descheduled is then the
> 	> interesting part. I suspect an OS scheduling quirk on 
> multi-core, but need
> 	> more information.
> 	
> 	>>>>>    private long doIt() { 
> 	>>>>>        long startTime = System.currentTimeMillis();
> 	>>>>>        for(int i = 0; i < howMany; i++) {
> 	>>>>>            new Thread(new Worker()).start();
> 	>>>>>        } 
> 	>>>>>        while(!finished);
> 	>>>>>        long endTime = System.currentTimeMillis();
> 	>>>>>        return (endTime - startTime);
> 	>>>>>
> 	>>>>>    } 
> 	
> 	Historically, I've found that busy waits like the above 
> are problematic.  I'd go
> 	along with David's comment/thought and try
> 	
> 	        while(!finished) Thread.yield();
> 	
> 	or something else to cause it to get descheduled for a 
> whole quanta for each 
> 	check rather than busy waiting for a whole quanta which 
> will keep at least one
> 	CPU busy doing nothing productive.
> 	
> 	Gregg Wonderly
> 	
> 
> 
> 
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.



More information about the Concurrency-interest mailing list