Interface Condition - bind/unbind ?!

Alexander Terekhov TEREKHOV@de.ibm.com
Thu, 31 Jan 2002 19:46:54 +0100


> Hi Alexander; I'm happy to see that you subscribed to this list!

Hi Doug; that's a GREAT/MANDATORY place to be for
anyone occasionally ;-) doing *concurrent* Java
(== OO) programming! You and others do a terrific
job with the 133/166 JSRs!! I only wish that such
amount of deep thinking would some day be applied
to PTHREADS/C++: OO/type-safe/less-error-prone-than-C/
easy C++ concurrent programming. BTW, that is actually
my second/"hidden" agenda to be here ;-) partly I
just want to steal ideas, which would help me in
my private/hobby efforts with respect to "MY
PTHREADS++" - a C++ wrapper library; the beginning
(rather chaotic stuff) is here:

http://www.terekhov.de/mythread.c
http://www.terekhov.de/thread_ptr.txt
(Pardon me for my poor English and late-night writting)

And sorry for off-topic stuff, I just thought that
someone on the list here might have some interest/
time to take a look and perhaps even help ;-)

> The supplied implementations of Condition won't be rebindable.
> The reasons are similar to the ones stated by some people in that
> newsgroup thread: It reduces the likelihood of error and is more
> efficient for the vastly most common case.

Why would an explicit way (without a need to "re-initialize")
to *change* the associated lock would make some problems with
respect to errors (error checking) and/or efficiency?

Or are you just worried with respect to an extra "unbound"
state?

Please clarify!

[...class RebindableCondition implements Condition...]

Yep, that would work just fine (except the
need to "re-init", which I somewhat dislike ;-).

regards,
alexander.



Doug Lea <dl@cs.oswego.edu>@altair.cs.oswego.edu on 01/31/2002 02:05:36 AM

Please respond to dl@cs.oswego.edu

Sent by:  concurrency-interest-admin@altair.cs.oswego.edu


To:   Alexander Terekhov/Germany/IBM@IBMDE
cc:   concurrency-interest@altair.cs.oswego.edu
Subject:  Re: Interface Condition - bind/unbind ?!




Hi Alexander; I'm happy to see that you subscribed to this list!

> Are there any reasons why there is no interface to bind/unbind
> a condition to(another)/from a corresponding lock object?
>
> http://groups.google.com/groups?as_umsgid=slrn9ehssd.hq.kaz%40cafe.net

The supplied implementations of Condition won't be rebindable.
The reasons are similar to the ones stated by some people in that
newsgroup thread: It reduces the likelihood of error and is more
efficient for the vastly most common case.

However, it is not hard to create your own Condition implementation
class that is rebindable. (Condition is an interface.)
You can write something like:

class RebindableCondition implements Condition {
  private Condition delegate;

  RebindableCondition(Object l) {
    delegate = Locks.createConditionFor(l);
  }

  void await() ... { delegate.await(); }
  // etc

  void rebind(Object l) {
    delegate = Locks.createConditionFor(l);
  }
}

Where I left out the necessary internal synchronization, and the error
checking that would be needed, both of which would take some thought.
Creating a new Condition for each rebind is more expensive than
resetting a field, but all in all, I think this is the right tradeoff.
It IS a rare (and rarely recomendable) usage, and even here, rebinds are
infrequent, so this strategy ought to be competitive.

Do you agree?

--
Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA
dl@cs.oswego.edu 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest