66.47.27.36: /* More flexibility by using a Lock */ - 2010-04-25 19:57:12

More flexibility by using a Lock

←Older revision Revision as of 19:57, 25 April 2010
Line 43: Line 43:
My two [[wikipedia::Czech_koruna|Kč]].
My two [[wikipedia::Czech_koruna|Kč]].
--[[User:JaroslavTulach|JaroslavTulach]] 19:45, 22 April 2010 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 19:45, 22 April 2010 (UTC)
 +
 +
There are static [[factory]] methods available for creating the ReenterableLock and the ReenterableDualLock, as well as the ReenterableReadWriteLock that supports the Sun Microsystems ReadWriteLock interface. I separate the [[ClientAPI]] as public methods from the [[ProviderAPI]] as protected methods. Most of the protected methods are abstract to allow a provider to offer an alternative implementation through subclassing. The default implementation provides enough information for an alternative provider to add more functionality through subclassing. Please remember that this library has a very limited purpose of protecting threads and virtual tasks from stepping on each other. As it stands now, it is easy to start using it as is, and to add more stuff to it as needed. Thank you. Jeffrey D. Smith

JaroslavTulach: /* More flexibility by using a Lock */ - 2010-04-22 19:45:17

More flexibility by using a Lock

←Older revision Revision as of 19:45, 22 April 2010
Line 37: Line 37:
Two cents worth. Your mileage may vary.
Two cents worth. Your mileage may vary.
 +
 +
 +
I looked at the [[API]] of your javamutex library and I found that by exposing less it could do more. I'd recommend use of [[factory]] methods rather than exposing subclassable classes and also clearly separating [[ClientAPI]] from [[ProviderAPI]]. [[ClarityOfTypes]] or at least [[ClarityOfAccessModifiers]] would not hurt either.
 +
 +
My two [[wikipedia::Czech_koruna|Kč]].
 +
--[[User:JaroslavTulach|JaroslavTulach]] 19:45, 22 April 2010 (UTC)

66.47.27.36: /* More flexibility by using a Lock */ - 2010-04-20 19:11:06

More flexibility by using a Lock

←Older revision Revision as of 19:11, 20 April 2010
Line 32: Line 32:
== More flexibility by using a Lock ==
== More flexibility by using a Lock ==
-
The Java developer should consider using Lock to improve flexibility over the Java monitor. I developed a library in 100% pure Java at https://sourceforge.net/projects/javamutex/ to support the java.util.concurrent.locks.Lock API. It uses the hidden Java monitor for very brief code paths to support the memory synchronization requirements of a Lock and to prevent interference from client code trying to synchronize on the Lock instance. My JavaMutex project on SourceForge.net is 100% pure Java, so it will run on any tiger-compliant Java Virtual Machine, and it open source and freely redistributable.
+
The Java developer should consider using Lock to improve flexibility over the Java monitor. I developed a library in 100% pure Java at https://sourceforge.net/projects/javamutex/ to support the java.util.concurrent.locks.Lock API. It uses the hidden Java monitor for very brief code paths to support the memory synchronization requirements of a Lock and to prevent interference from client code trying to synchronize on the Lock instance. My JavaMutex project on SourceForge.net is 100% pure Java, so it will run on any tiger-compliant Java Virtual Machine, and it's open source and freely redistributable.
I wrote it because I was uncomfortable relying the Sun Microsystems proprietary Lock support libraries that depend on the internal implementation of the Sun JVM (and also uses brief synchronized code paths).
I wrote it because I was uncomfortable relying the Sun Microsystems proprietary Lock support libraries that depend on the internal implementation of the Sun JVM (and also uses brief synchronized code paths).
Two cents worth. Your mileage may vary.
Two cents worth. Your mileage may vary.

66.47.27.36: /* More flexibility by using a Lock */ new section - 2010-04-20 19:07:01

More flexibility by using a Lock: new section

←Older revision Revision as of 19:07, 20 April 2010
Line 29: Line 29:
--[[User:JaroslavTulach|JaroslavTulach]] 12:56, 31 January 2010 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 12:56, 31 January 2010 (UTC)
 +
 +
== More flexibility by using a Lock ==
 +
 +
The Java developer should consider using Lock to improve flexibility over the Java monitor. I developed a library in 100% pure Java at https://sourceforge.net/projects/javamutex/ to support the java.util.concurrent.locks.Lock API. It uses the hidden Java monitor for very brief code paths to support the memory synchronization requirements of a Lock and to prevent interference from client code trying to synchronize on the Lock instance. My JavaMutex project on SourceForge.net is 100% pure Java, so it will run on any tiger-compliant Java Virtual Machine, and it open source and freely redistributable.
 +
 +
I wrote it because I was uncomfortable relying the Sun Microsystems proprietary Lock support libraries that depend on the internal implementation of the Sun JVM (and also uses brief synchronized code paths).
 +
 +
Two cents worth. Your mileage may vary.

JaroslavTulach at 12:56, 31 January 2010 - 2010-01-31 12:56:26

←Older revision Revision as of 12:56, 31 January 2010
Line 25: Line 25:
-Tim Boudreau
-Tim Boudreau
 +
 +
Right, this is the behavior. But it is not flaw of [[Java Monitor]], it is a design decision of the inventor of ''monitor'' concept. The appropriate solution would be to put the separate concept into separate records/classes. So [[Java]] is using the ''monitor'' concept correctly (in this case), but one may treat this as another indication that monitors are not really suitable for [[OOP]].
 +
 +
--[[User:JaroslavTulach|JaroslavTulach]] 12:56, 31 January 2010 (UTC)

JaroslavTulach at 12:52, 31 January 2010 - 2010-01-31 12:52:36

←Older revision Revision as of 12:52, 31 January 2010
Line 1: Line 1:
@Synchronized does look good for some cases. However, it does not address (at least not without writing just as much code as doing it without annotations) a second class of monitor usage bugs that I find is very common: Using a single lock for multiple resources. It is very common to see a pattern such as:
@Synchronized does look good for some cases. However, it does not address (at least not without writing just as much code as doing it without annotations) a second class of monitor usage bugs that I find is very common: Using a single lock for multiple resources. It is very common to see a pattern such as:
 +
<source lang="java">
public class Foo {
public class Foo {
private Bar bar;
private Bar bar;
Line 16: Line 17:
}
}
}
}
 +
</source>
While this code is correct in that it will compile and run as the user expects,
While this code is correct in that it will compile and run as the user expects,

Tim: Comment re using one monitor to protect unrelated resources - 2010-01-29 04:41:33

Comment re using one monitor to protect unrelated resources

New page

@Synchronized does look good for some cases. However, it does not address (at least not without writing just as much code as doing it without annotations) a second class of monitor usage bugs that I find is very common: Using a single lock for multiple resources. It is very common to see a pattern such as:

public class Foo {
private Bar bar;
protected synchronized replaceBar() {
bar = new Bar(xyz);
}
public synchronized Bar getBar() {
return bar;
}
public synchronized void addPropertyChangeListener (PropertyChangeListener pcl) {
...
}
public synchronized void removePropertyChangeListener (PropertyChangeListener pcl) {
...
}
}

While this code is correct in that it will compile and run as the user expects,
# There is much greater potential for deadlocks, and
# An application with such code can have thread liveness problems
because the same monitor is being used to protect two unrelated resources from access collisions.

-Tim Boudreau