Ha considerado el uso wait
/notify
(el equivalente a Monitor.Wait
y Monitor.Pulse
) en su lugar?
Querrá comprobar un poco si en realidad necesita esperar (para evitar condiciones de carrera) pero debería funcionar.
De lo contrario, algo como CountDownLatch
bien puede hacer lo que desee.
EDIT: Acabo de notar que CountDownLatch
es básicamente de "uso único" - no se puede restablecer el conteo más tarde, por lo que puedo ver. Es posible que desee Semaphore
en su lugar. Utilice tryAcquire
como éste para que retenga un tiempo de espera:
if (semaphore.tryAquire(5, TimeUnit.SECONDS)) {
...
// Permit was granted before timeout
} else {
// We timed out while waiting
}
Tenga en cuenta que esto es a diferencia de ManualResetEvent
hecho de que cada llamada con éxito a tryAcquire
reducirá el número de permisos - por lo que finalmente van a correr de nuevo. No puede hacer que se "establezca" permanentemente como podría con ManualResetEvent
. (Eso sería trabajar con CountdownLatch
, pero entonces no podría "reset" it :)
Pero, ¿y el aspecto del tiempo de espera? Por lo que leí en la documentación de CountDownLatch, no parece tener un valor de tiempo de espera que pueda interceptar o detener antes de que se agote el tiempo de espera hasta el final. Me gustaría tener un tipo de Java que pueda usar para esperar un tiempo de espera, y que pueda ser interceptado antes de que termine el tiempo de espera, como una anulación manual. ¡También, hola Sr. Skeet! ¿Como estas? Probablemente obtienes mucho, ¡pero tu libro es genial! – Orca
@Voulnet: Llamarías a 'await (tiempo de espera prolongado, unidad TimeUnit)' - que bloqueará durante la duración de tiempo de espera dada * o * regresará antes si el bloqueo se cuenta hacia abajo. Me alegra que te guste el libro :) –
Sí , la solución debe funcionar de maravilla ya que solo tengo un objeto esperando en cualquier momento. Gracias, Sr. Jon Skeet. – Orca