Memory Barriers Wrap-up

Sleeve Sealers

Sleeve Sealers — Mon, 28 Sep 2009 06:17:29 GMT

Many technological developments will give you, the customer, real advantages – using less film, using less energy and running faster production speeds reliably

re: Memory Barriers Wrap-up

Steve Dispensa — Tue, 21 Sep 2004 15:25:00 GMT

Steve:

Perhaps you could blog about some book recommendations, or online resources where one could read more about this subject?

re: Memory Barriers Wrap-up

Steve Dispensa — Tue, 21 Sep 2004 13:39:00 GMT

http://www-106.ibm.com/developerworks/java/library/j-jtp02244.html

Gives a great write up of the Java memory model, why it's broken and how they want to fix it...

Unsuprisingly there is a proposal for Read/write/both barriers.

re: JVM example

Steve Dispensa — Mon, 20 Sep 2004 19:46:00 GMT

Hrmm, view source on that last post to view the indentation correctly -- it makes much more sense that way ;)

re: JVM example

Steve Dispensa — Mon, 20 Sep 2004 19:44:00 GMT

Breaker 19, There's a big pile up on i-90: 933, 1053

Yes, that's right... read the code and see why. If you uncomment out the syncronized blocks it works just fine. Code follows:

public class Test
{
public static boolean keepTruckn = true;

static public class T1
extends Thread
{
int goods[] = null;

public T1( int goods[] )
{
this.goods = goods;
}

public void run()
{
while ( keepTruckn )
{
//synchronized ( goods )
//{
goods[0]++;
goods[1]++;
//}
}
}
}

static public class T2
extends Thread
{
int goods[] = null;

public T2( int goods[] )
{
this.goods = goods;
}

public void run()
{
while ( true )
{
//synchronized ( goods )
//{
if ( (goods[0] != goods[1]) && keepTruckn )
break;
//}
}

System.err.println("Breaker 19, There's a big pile up on i-90: " + goods[0] + ", " + goods[1] );
keepTruckn = false;
}
}

public static void main( String args[] )
{
int goods[] = new int[2];
goods[0] = goods[1] = 0;

T1 t1 = new T1( goods );
T2 t2 = new T2( goods );

t1.start();
t2.start();

try
{
t2.join();
t1.join();
}
catch ( Exception e ) { }
}
}

JVM Memory Barrier

Steve Dispensa — Mon, 20 Sep 2004 18:47:00 GMT

Java doesn't really go that close to the underlying architecture to be as specific as saying 'do all of this before anything else' as far as I know. You would have to do something along the lines of a mutex or spinlock via the synchroized keyword in java. In java, synchronized can be added to any method's declaration to make it 'mutexed' across each instance of the object. For instance, if you make an object with two methods, each synchronized, and created one instance of the object. When instantiated, any thread can only run one of those methods at a time. In addition, additional instances of the object are only restricted by THEIR instance... meaning that both objects could run method 1 at the exact same time, but one object cannot run both of it's methods at the same time.

This is, in my opinion, handy, yet limiting. luckily, java allows you to use the syncronized keyword in another more useful way. You can basically treat any Object (I say Object because Object is the base class for any object in java) as a mutex/spinlock. If you want to use specific locks, just do synchronized (someObj) { code; } around any code that you want to be locked based on someObj. Only one synchronized (someObj) { code; } block can run at a time for the intance of someObj in that scope. If you want to do a process wide lock, declare a static Object outside your class instance (like at the top of a .java file) and do syncrhonized blocks off of it. This is equivilant to mutexes in the java world.

Another handy feature of java's threading setup is the fact that each object you use or define, as long as it's a real object like Integer and not a language literal like int, can be used to synchronize, notify, and wait on. The Object base class has methods called wait, notify, notifyAll. One version of the wait method takes a timeout also. Notify will cause one thread that is waiting to wake up. NotifyAll will wake them all up. Very handy indeed.

re: Memory Barriers Wrap-up

Steve Dispensa — Mon, 20 Sep 2004 18:05:00 GMT

I always manage to forget something... sigh...

The same issues show up in usermode code, by the way. I didn't mean to imply that this was kernel-mode-only. In fact, the SDK has MemoryBarrier() for the same reason. For those of you who invest your time in the .Nyet silliness, there's even Thread.MemoryBarrier for you.

Anyone know how to do this in a JVM? :-)

The sdk documentation idiotically says that you only have to use memory barriers "if you know your code will be running on multiprocessor architectures using weak-ordering CPUs". Hmm... Let me see... that seems to include all hyperthreaded P4s, doesn't it?

Even more hmmm... I have no idea if the two virtual CPUs that are exposed by an HT P4 have the same memory barrier issues. Theoretically Intel could keep the entire physical chip self-consistent (in fact, there are statements to that effect in the manuals, but they're in a different context).