> More realistically, there could be a wait in the constructor dependent on
> a notify in the thread. This is left as an exercise for the reader.
Well, personally, I would feel really "uncomfortable" knowing
that someone could even touch NOT FULLY constructed object(s)
(even with Java's ZERO "pre-init", partially addressing this
"problem").
With "SUSPEND/RESUME" w.r.t thread.start I just meant that
a "request" to start a thread could remain pending until
completion of poly-object construction to prevent exposing
not-fully constructed objects to a newly created/started
thread(s) (with actual start being the memory sync.point).
I am NOT a friend of async.suspend... however, I would like
to note that async.suspend COULD be made deadlock-free using
something along the lines of pthread_atfork() PREPARE and
PARENT handlers -- sort of "async.suspend-handlers"... which
might be useful in a rather limited set/domain of applications.
regards,
alexander.
Jeremy Manson <jmanson@cs.umd.edu>@cs.umd.edu on 03/12/2002 04:54:17 PM
Please respond to Jeremy Manson <jmanson@cs.umd.edu>
Sent by: owner-javamemorymodel@cs.umd.edu
To: javamemorymodel@cs.umd.edu
cc:
Subject: Re: JavaMemoryModel: Thread starting in constructors
>
> How about:
>
> f) the thread will be SUSPENDED and RESUMED automatically
> on exit from the most-derived class constructor (exceptions
> aside);
That doesn't solve the problem in terms of the semantics. There is no
implicit synchronzation associated with Thread.suspend() and
Thread.resume() (nor should there be, I suspect; it's good to stay away
from those methods). Even if you were to use wait/notify, it isn't a good
idea because the constructor may never end (unless you mean that this only
applies to threads started on the last line of the constructor), viz.:
class A {
int x;
final int y;
Object lock = new Object();
public A(int a, int b) {
x = a;
y = b;
new Thread() {
public void run() {
System.out.println("x = " + x + ", y = " + y);
}}.start();
}
while (true) {
}
}
More realistically, there could be a wait in the constructor dependent on
a notify in the thread. This is left as an exercise for the reader.
> or, even better:
>
> g) a rather simple mechanism of POST-constructors could be
> introduced to SAFELY/MEANINGFULLY exploit the polymorphic
> behavior (publish this, start threads, etc) at "construction"
> time without all those silly "manual" init()s/factories/final
> wrappers, etc.
That would be nice, but it wouldn't help existing code. That probably
needs its own JSR, too.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:38 EDT