சில நுணுக்கங்கள்

"வணக்கம், அமிகோ!"

"மேலும் ஒரு ஜோடி விவரங்கள். அதை நடைமுறை ஆலோசனை என்று அழைக்கலாம்."

"உங்களிடம் ஒரு முறை உள்ளது என்று வைத்துக்கொள்வோம், அது எதையாவது எதிர்பார்த்து, ஒரு நிபந்தனை திருப்தி அடையும் வரை தூங்கிவிடும்."

public synchronized Runnable getJob()
{
 if (jobs.size() == 0)
  this.wait();

 return jobs.remove(0);
}

"ஜாவா ஆவணங்கள் காத்திருப்பு முறையை ஒரு லூப்பில் அழைப்பதை மிகவும் வலியுறுத்துகிறது:"

public synchronized Runnable getJob()
{
 while (jobs.size() == 0)
  this.wait();

 return jobs.remove(0);
}

"ஏன்? விஷயம் என்னவென்றால், நூல் எழுந்தால், நிபந்தனை திருப்தி அடைந்தது என்று அர்த்தமல்ல. ஒருவேளை இருபது தூங்கும் நூல்கள் இருந்திருக்கலாம். அவை அனைத்தும் எழுந்தன, ஆனால் ஒருவரால் மட்டுமே பணியை எடுக்க முடியும்."

"தோராயமாகச் சொன்னால், 'தவறான அலாரங்கள்' இருக்கலாம். ஒரு நல்ல டெவலப்பர் இதை கணக்கில் எடுத்துக்கொள்ள வேண்டும்."

"நான் பார்க்கிறேன். அறிவிப்பைப் பயன்படுத்துவது எளிதானது அல்லவா?"

"சரி, பட்டியலில் ஒன்றுக்கு மேற்பட்ட பணிகள் இருந்தால் என்ன செய்வது? தேர்வுமுறைக்காக பொதுவாக Notify பரிந்துரைக்கப்படுகிறது. மற்ற எல்லா நிகழ்வுகளிலும், notifyAll முறையைப் பயன்படுத்த பரிந்துரைக்கப்படுகிறது."

"சரி."

"ஆனால் இன்னும் நிறைய இருக்கிறது. முதலில், யாராவது உங்கள் வகுப்பை மரபுரிமையாக்கி, தங்கள் சொந்த முறைகளைச் சேர்த்து, காத்திருக்க/அறிவிக்கும்அனைத்தையும் பயன்படுத்தும் சூழ்நிலை இருக்கலாம். வேறுவிதமாகக் கூறினால், அனைத்து ஜோடிகளும் ஒரே பொருளில் சுதந்திரமாக காத்திருக்கும்/அறிவிக்கும் சூழ்நிலை இருக்கலாம். மற்றும் ஒருவரையொருவர் பற்றி தெரியாது. அதனால் நீங்கள் என்ன செய்ய வேண்டும்?"

"எப்பொழுதும் லூப்பில் காத்திருப்பை அழைக்கவும், லூப்பின் முடிவின் நிலை உண்மையா என்று சரிபார்க்கவும்!"

"சரி. உங்களால் இதிலிருந்து தப்பிக்க முடியாது என்பதை தெளிவுபடுத்துவதற்காக, பல டெவலப்பர்கள் சில சமயங்களில் த்ரெட்கள் தாமாகவே விழித்துக் கொள்வதைச் சுட்டிக்காட்டுகிறார்கள். தற்செயலாக எழுப்பப்படாது என்று உத்தரவாதம் அளிக்கப்படும் இழைகள். இது ஒரு குறியீட்டு தேர்வுமுறையின் பக்க விளைவு போல் தெரிகிறது. ஜாவா இயந்திரத்தை இயக்குகிறது."

"ஐயோ. புரிந்தது. லூப் இல்லாமல், காத்திருக்கும் முறை நல்லதல்ல."