Re: Bad Multi-Threading Performances

[Matthew Strayer]

Here is some code which implements the reader/writer
locking scheme.  Instead of having an infinite while
loop, it will abort if the thread is interrupted...I
believe the code correctly handles the exception

-Matt

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: Bad Multi-Threading Performances (attached this time)

[Matthew Strayer]

Here is some code which implements the reader/writer
locking scheme.  Instead of having an infinite while
loop, it will abort if the thread is interrupted...I
believe the code correctly handles the exception.


-Matt

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
 RWMonitor.java
 ReadersPreferredMonitor.java
 WritersPreferredMonitor.java

Re: Bad Multi-Threading Performances

[Matthew Harrison]

  
  
Since read access still predominates, I'm interested in code design patterns
that do not require locks for reads, but still deal with writes safely.  Anyone
have any good pointers?
  
  One approach is to use a readers/writers scheme where
  the readers are preferred, allowing multiple threads
  to read at the same time.  Synchronization is still
  required but only for short periods of time for
  checking sentinel values.  One would code like:
  
  // read method
  public Object someMethod() {
try {
  _lock.startReading(); // acquires and releases
  monitor
  // do some reading
} finally {
  _lock.stopReading();
}
  }
  

Have a look at the source for the javax.swing.text package. 
 The AbstractDocument class has a similar scheme: readLock()/readUnlock()
 writeLock()/writeUnlock()
 
 Or look at Doug Lea's Concurrent Programming in Java. Here's the online
 supplement with links to source code.
 
 http://gee.cs.oswego.edu/dl/cpj/
 
 
 Matthew Harrison.
 

Re: Bad Multi-Threading Performances

[Craig R. McClanahan]

Van der Auwera Koen wrote:

 Hello,

 Why is it that struts uses objects that are synchronized (hashtable, vector)
 ?
 This really sucks in a multi-threaded environment!!

 I mean, Struts is crowded with objects that could be thought as 'read-only'
 (initialized at the server startup)
 Because the Hashtable methods are synchronized, this causes a huge
 performance drop in a multi-client environment.
 Maybe a better way to handle this is to use the JDK1.2 hashmap


 Some defense please...


Not defense, necessarily, but a little history is useful ...

When Struts started out, JDK 1.1 compatibility was considered very important by
the community -- so we stuck with JDK 1.1 collection classes.  That feeling has
only very recently changed, and a migration to Java2 collection classes has not
yet been completed.

That being said, many/most of these "read only" collections can still be changed
at runtime.  For example, the cache of Action instances is modified every time
you call a new Action for the very first time.  Others (such as the set of
defined mappings) can be dynamically changed if you include one of the standard
Actions (see package org.apache.struts.actions) that lets you manage this
remotely.

Since read access still predominates, I'm interested in code design patterns
that do not require locks for reads, but still deal with writes safely.  Anyone
have any good pointers?


 Koen Van der Auwera


Craig

Re: Bad Multi-Threading Performances

[Matthew Strayer]

 Since read access still predominates, I'm interested
 in code design patterns
 that do not require locks for reads, but still deal
 with writes safely.  Anyone
 have any good pointers?
 

Basic CS that should be covered in any OS course. ;-)

One approach is to use a readers/writers scheme where
the readers are preferred, allowing multiple threads
to read at the same time.  Synchronization is still
required but only for short periods of time for
checking sentinel values.  One would code like:

// read method
public Object someMethod() {
  try {
_lock.startReading(); // acquires and releases
monitor
// do some reading
  } finally {
_lock.stopReading();
  }
}

// write method
public void someOtherMethod(Object o) {
  try {
_lock.startWriting();
// do some writing
  } finally {
_lock.stopWriting();
  }
}

I'll dig up my small thread library at work tomorrow
if you want it.

Another approach is to use "immutable" objects that
copy only on writes.  Additionally, although not
appropriate for Struts, one could use a single thread,
as in Swing, for performing all writes and a message
queue for queueing the changes to be performed.

-Matt

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/