मैंने पाया कि ReentrantReadWriteLock का लिखना ताला यह जांचने के लिए isHeldByCurrentThread() विधि प्रदान करता है कि क्या इनवॉकिंग थ्रेड उस लॉक को रखता है या नहीं।क्यों वर्तमान धागे को ReentrantReadWriteLock के रीड लॉक को जांचने का कोई तरीका नहीं है?
लेकिन रीड लॉक के लिए कोई संबंधित isHeldByCurrentThread() विधि नहीं है। क्यों नहीं?
मुझे लगता है कि उत्तर डौग लीस की टिप्पणी में है कि उसने इस मुद्दे के लिए दिया: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6207928।
डौग ली लिखते हैं:
वर्तमान डिजाइन और व्यवहार जानबूझकर कर रहे हैं। रीड-लॉक को आमतौर पर स्वामित्व की धारणा के लिए परिभाषित नहीं किया जाता है, इसलिए स्वामित्व का परीक्षण नहीं किया जा सकता है। ... जेएसआर 166 ईजी को वैकल्पिक रूप से प्रति-थ्रेड रीड-होल्ड ट्रैकिंग का समर्थन करने के लिए कुछ अनुरोध प्राप्त हुए हैं। ऐसा करने से लॉक ओवरहेड में काफी वृद्धि होगी, इसलिए वैकल्पिक निर्माण पैरामीटर द्वारा शासित होने की आवश्यकता होगी। हम इसमें देख रहे हैं।
ReentrantReadWriteLock.getReadHoldCount() नौकरी करने लगता है।
जब तक आपका कोड पुनर्विक्रेता रीडलॉक्स नहीं कर रहा है, यह – Renan
काम करेगा, नहीं। मान लें कि थ्रेडए ने रीड लॉक हासिल किया है। गिनती अब 1 है। थ्रेडए लॉक को रिलीज़ करने से पहले, थ्रेडब getReadHoldCount()> 0 पर निर्भर करता है और "संरक्षित" कोड में प्रवेश करता है। अब थ्रेडए लॉक को रिलीज़ करता है, लेकिन थ्रेडबी अभी भी संरक्षित कोड में है। थ्रेडसी खेल में आता है, एक लेखन लॉक प्राप्त करता है, इसे प्राप्त करता है (क्योंकि पाठक गिनती शून्य है), और कुछ डेटा अपडेट करता है। -> थ्रेडब असंगत डेटा देखता है। – Heri
ठीक है, मुझे समझ में आया। फिर भी मुझे उम्मीद थी कि वर्तमान थ्रेड में ReentrantReadWriteLock का रीड लॉक है या नहीं। – rollaeriu360