[concurrency-interest]PoolExecutor & Lock

Levente Farkas lfarkas@mindmaker.hu
Thu, 21 Feb 2002 14:56:31 +0100


hi,
although I already send it to DL, but may be the list also interested.

a few comment for java.util.concurrent. a PoolExecutor would be very useful
in this package too, although but may be with a smaller interface, than
in DL's original util.concurrent package.
eg. I prefere one setBlockingPolicy fuction with an exception which was
thrown when the executable can't execute (eg. the pool, and the queue is 
full). it's an important to be able to recognize somehow.

another general request would be for all Lock (if there be such an interface
as sync in your original sync). I always prefer smaller interfaces. lock
already has 8 functions:-( 
I REALY prefere symetric names for lock (like lock/unlock/tyrlock or may
be others), but acquire/release is not my favorite. this names remember
me to those windows api fucntions like waitforsingleobject... of course
it's just a matter of taste, but would be cleaner (at least for me:-)

another thing for lock: it'd be usefule if I can mix the "old sytle"
synchronize and the new acquire. what I mean the lock can be the monitor
on the lock itself. eg:
-----------
Lock l =...
try
{
  l.lock();
  try
  {
    ....
  }
  finally 
  { 
    l.unlock();
  }
}
catch (InterruptedException e)
{
  ...
}
-----------
would be the same as:
-----------
Lock l =...
synchroznied(l)
{
...
}
-----------
this means when the synchronization appear in a block than I can do
the safer and much cleaner code. actually I don't know (since I don't 
think about it) whether it's possible or not, but the current lock
semantics are make the code less readable. it'd be useful even if we
have to change/extend jvm or lang spec

one more thing about it, for ReadWriteLock it'd be also useful if the 
write lock would be equal to the ReadWriteLock's object lock, ie.:
-----------
ReadWriteLock rw =...
Lock l = rw.getWriteLock();
try
{
  l.lock();
  try
  {
    ....
  }
  finally 
  { 
    l.unlock();
  }
}
catch (InterruptedException e)
{
  ...
}
-----------
would be equal something like:
-----------
ReadWriteLock rw =...
synchroznied(rw)
{
}
-----------
this style is cleaner, natural and in this case this api realy fit into 
the current java spec. IMHO.
yours.

-- 
  Levente                               "Si vis pacem para bellum!"