tengiz wrote:Sabina wrote:То есть на С++, чтобы написать вот это... тоже шесть строк кода уйдет?
...На C++ при наличии аналогичной библиотеки классов...
tengiz wrote:Cабина - Вы какой-то странный вопрос задали. На C++ при наличии аналогичной библиотеки классов не просто то же количество строк понадобится, а буквально те же строки. Может, Вы что-то другое хотели спросить да просто не очень ясно сформулировали?
Ну хорошо, не С++, а lower level languages
WildVlad wrote:tengiz wrote:Sabina wrote:То есть на С++, чтобы написать вот это... тоже шесть строк кода уйдет
...На C++ при наличии аналогичной библиотеки классов...
Более того, готов поспорить, что Сан эту библиотеку (или идею для неё) где-то позаимствовал, как он это обычно делает в последнее время.
Sabina wrote:Интересно у кого они могли позаимстовать JVM monitoring?
Sabina wrote:Интересно у кого они могли позаимстовать JVM monitoring?
Sabina wrote:Мне кажется это нормальная эволюция языков программирования. Мне искренне непонятно почему наличие такой же библиотеки в С++ вас бы устроило, а в Java раздражает?
hooch wrote:Автораспараллеливание средствами языка программирования???
Blake wrote:http://www.alphaworks.ibm.com/tech/mbeaninspector etc
Таких?tengiz wrote: ...в смысле привнесения в параллельное программирование качественных и высокоэффективных абстракций.
WildVlad wrote:hooch wrote:
А вот уже компилятор может полагаться на среду исполнения.
Ну а когда уже и компилятор будет знать о авто-распараллеливании, то и определённые индивидуумы могут попытаться это использовать
Sabina wrote:Хотя кто его знает, может и сперли идею этих тулов у IBM
WildVlad wrote:*do not start thread from constructor, etc.
Спорное утверждение. Грозит только потерей ссылки на нить при исключении ниже по тексту конструктора.
Consider the following classes A and B:Code: Select all
class A implements Runnable
{
public A ()
{
( new Thread ( this ) ).start ();
}
public void run ()
{
doSomething ();
return;
}
public void doSomething ()
{
return;
}
}
class B extends A
{
private Object object;
public B ()
{
// first line has an implicit call to this.A()
object = new Object ();
}
public void doSomething ()
{
synchronized ( this )
{
try
{
object.wait ();
}
catch ( InterruptedException ie ) {}
}
return;
}
}
I believe that constructor invocation is recursive.
The Java compiler places an implicit call to A's constructor on the first line of B's constructor.
Consider the following line of client code:
B b = new B ();
This invokes B's constructor. Before B's constructor can allocate memory for member object, A's constructor is run. A's constructor calls
( new Thread ( this ) ).start ();
This line starts a new thread running A's method run() (and this could happen even before control is returned to A's constructor which will finish before control is
returned to B's constructor). A.run () calls method doSomething(). While there is a method doSomething() in class A, there is also a method doSomething() in class B. Guess what? Class B's doSomething() method overrides class A's doSomething() method and is thus called in place of class A's doSomething() method (we
are constructing an instance of class B after all).
Class B's doSomething() method calls object.wait().
But, class B's constructor might not even have finished executing. Thus, object may not have been initialized and the call to object.wait() could produce a NullPointerException. It is important to add that this will not always happen. Under some JVMs, it is possible that this will never happen. Then again, it could happen. This is an instance of a RACE CONDITION. Race Conditions happen when data is not perfectly protected with synchronization.
