Подскажите, за счет чего удалось добится лучшего быстродействия, чем нативные методы класса Object?
Я так и не разобрался, как оно работает внутри. Может, подскажете?
Еще интересно, существует ли аналог

DWORD WINAPI WaitForMultipleObjects(
  __in  DWORD nCount,
  __in  const HANDLE* lpHandles,
  __in  BOOL bWaitAll,
  __in  DWORD dwMilliseconds
);

с учетом флажка bWaitAll?

Здравствуйте, http://chabster.blogspot.com/, Вы писали:

HCB>Подскажите, за счет чего удалось добится лучшего быстродействия, чем нативные методы класса Object?
Кому удалось? Оно точно быстрее?

ReentrantLock вроде бы работает точно так же, как и обычная блокировка — сначала крутит спинлок, а потом добавляет себя в очередь ожидания и паркует поток.

HCB>Еще интересно, существует ли аналог
HCB>

HCB>DWORD WINAPI WaitForMultipleObjects(
HCB>  __in  DWORD nCount,
HCB>  __in  const HANDLE* lpHandles,
HCB>  __in  BOOL bWaitAll,
HCB>  __in  DWORD dwMilliseconds
HCB>);
HCB>

HCB>с учетом флажка bWaitAll?
CyclicBarrier?

PS: на будущее — не рекомендуется считать, что у всех читателей стоит MSDN и они знают WinAPI...

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, http://chabster.blogspot.com/, Вы писали:

HCB>>Подскажите, за счет чего удалось добится лучшего быстродействия, чем нативные методы класса Object?
C>Кому удалось? Оно точно быстрее?

В сети по бенчмаркам заявляют, что ReentrantLock лучше работает под большим контешнешом. http://www.ibm.com/developerworks/java/library/j-jtp10264/

C>ReentrantLock вроде бы работает точно так же, как и обычная блокировка — сначала крутит спинлок, а потом добавляет себя в очередь ожидания и паркует поток.
Паркование — вызов нативного метода Unsafe.park(boolean, long)? Как же может получится быстрее, если Object.wait() тоже реализован нативно. При этом ReentrantLock выполняет еще некоторое кол-во управляемого кода перед вызовом Unsafe.park.

HCB>>Еще интересно, существует ли аналог
HCB>>

HCB>>DWORD WINAPI WaitForMultipleObjects(
HCB>>  __in  DWORD nCount,
HCB>>  __in  const HANDLE* lpHandles,
HCB>>  __in  BOOL bWaitAll,
HCB>>  __in  DWORD dwMilliseconds
HCB>>);
HCB>>

HCB>>с учетом флажка bWaitAll?
C>CyclicBarrier?

Насколько я помню, CyclicBarrier — ожидать все потоки. Есть ли возможность ожидать любой поток? Можно получить через CountDownLatch(1), но тогда невозможно определить какой поток освободил блокировку.

C>PS: на будущее — не рекомендуется считать, что у всех читателей стоит MSDN и они знают WinAPI...
Виноват

Здравствуйте, http://chabster.blogspot.com/, Вы писали:

C>>Кому удалось? Оно точно быстрее?
HCB>В сети по бенчмаркам заявляют, что ReentrantLock лучше работает под большим контешнешом. http://www.ibm.com/developerworks/java/library/j-jtp10264/
В это верю. ReentrantLock должен быть немного лучше при большом contention'е и малой длине ожидания.

Synchronized должен лучше работать при долговременном ожидании и небольшом contention'е.

HCB>Паркование — вызов нативного метода Unsafe.park(boolean, long)? Как же может получится быстрее, если Object.wait() тоже реализован нативно. При этом ReentrantLock выполняет еще некоторое кол-во управляемого кода перед вызовом Unsafe.park.
Управляемый код там очень простой, с этим проблем нет. Wait зато поддерживает ещё notify/notifyAll.

C>>CyclicBarrier?
HCB>Насколько я помню, CyclicBarrier — ожидать все потоки. Есть ли возможность ожидать любой поток? Можно получить через CountDownLatch(1), но тогда невозможно определить какой поток освободил блокировку.
Я бы, лично, использовал для этого SyncrhonousQueue.

Здравствуйте, Cyberax, Вы писали:

HCB>>В сети по бенчмаркам заявляют, что ReentrantLock лучше работает под большим контешнешом. http://www.ibm.com/developerworks/java/library/j-jtp10264/
C>В это верю. ReentrantLock должен быть немного лучше при большом contention'е и малой длине ожидания.

С чего бы? Ты ж сам сказал, что и там и там спин-лок+ожидание.