JBUG - JDK8 Study(Concurrency_01)

Jboss User Group Study - 2014.07.02(수)

주호씨 덕분에 하게 된 스터디! 감사르~~

Concurrency(동시 실행)

오늘 기억에 남는 내용은..

Interrupts

An interrupt is an indication to a thread that it should stop what it is doing and do something else. It's up to the programmer to decide exactly how a thread responds to an interrupt, but it is very common for the thread to terminate. This is the usage emphasized in this lesson.

A thread sends an interrupt by invoking interrupt on the Thread object for the thread to be interrupted. For the interrupt mechanism to work correctly, the interrupted thread must support its own interruption.

Supporting Interruption

How does a thread support its own interruption? This depends on what it's currently doing. If the thread is frequently invoking methods that throw InterruptedException, it simply returns from the run method after it catches that exception. For example, suppose the central message loop in the SleepMessages example were in the run method of a thread's Runnable object. Then it might be modified as follows to support interrupts:

for (int i = 0; i < importantInfo.length; i++) {

    // Pause for 4 seconds

    try {

        Thread.sleep(4000);

    } catch (InterruptedException e) {

        // We've been interrupted: no more messages.

        return;

    }

    // Print a message

    System.out.println(importantInfo[i]);

}

Many methods that throw InterruptedException, such as sleep, are designed to cancel their current operation and return immediately when an interrupt is received.

// 보라색 부분을 질문 하였다. InterruptedException을 발생시키는 sleep같은 메소드! 들은 디자인 되어있다고 한다.

// 현재의 작업을 취소하고 리턴한다고! 즉시 interrupt 를 반환! 

그런데 토론을 하다보니 내가 생각한 것과 다른 의견이 나왔다. sleep중에 Interrupt가 발생 되어질 때 InterruptedException가 발생되어지고 바로 return을 한다는 것이다. 그것을 해주는 부분이 아래의 부분???

} catch (InterruptedException e) {              // We've been interrupted: no more messages.         return;     }

결론은 sleep같은 많은 메소드들이 현재 작업 취소 및 즉시 리턴 하는 것으로~~:D

또한 아래와 같이 invoking없이 장시간 작업하는 쓰레드가 InterruptedException가 발생 한다면! 체크하여 리턴!

다시 읽어보고 정리한 내용은 이 글의 맨 아래에 있습니다. ㅎㅎ 

What if a thread goes a long time without invoking a method that throws InterruptedException? Then it must periodically invoke Thread.interrupted, which returns true if an interrupt has been received. For example:

for (int i = 0; i < inputs.length; i++) {

    heavyCrunch(inputs[i]);

    if (Thread.interrupted()) {

        // We've been interrupted: no more crunching.

        return;

    }

}

혹은! 아래와 같이 throw new InterruptedException();를 해줄 수 있다!

In this simple example, the code simply tests for the interrupt and exits the thread if one has been received. In more complex applications, it might make more sense to throw an InterruptedException:

if (Thread.interrupted()) {

    throw new InterruptedException();

}

This allows interrupt handling code to be centralized in a catch clause.

The Interrupt Status Flag

The interrupt mechanism is implemented using an internal flag known as the interrupt status. Invoking Thread.interrupt sets this flag. When a thread checks for an interrupt by invoking the static method Thread.interrupted, interrupt status is cleared. The non-static isInterrupted method, which is used by one thread to query the interrupt status of another, does not change the interrupt status flag.

By convention, any method that exits by throwing an InterruptedException clears interrupt status when it does so. However, it's always possible that interrupt status will immediately be set again, by another thread invoking interrupt.

주저리 : 테스트와 아직까지 페이스북에서는 토론이 진행되고 있다 ㅎㅎㅎ 굿!

2번째 참여! 정말 좋은 것 같다. ㅎㅎㅎ 

열심히 준비해서 나도 발표 한번 해봐야지! ㅋㅋㅋ

아..그런데 무슨일이지...방문자가 갑작스레 어제 1천명, 오늘은 900명이네..와우!! 

    - END? not yet :D -

facebook에서 열띤 토론이 벌어져서 다시 한번 읽어보고 정리해보았다. 위의 결론과는 다르다.

- END ? -