تناسق الذاكرة java lockupport

Question

جافا 6 أسئلة API. هل الدعوة LockSupport.unpark(thread) عند يحدث قبل العلاقة مع العودة من LockSupport.park في الخيط فقط لم يسرد؟ أظن بشدة أن الإجابة هي نعم ، لكن يبدو أن Javadoc يذكرها بشكل صريح.

Answer 1

لقد بحثت على الرغم من رمز JDK ويبدو أن طرق دعم الأقفال تسمى عادة خارج كتل المزامنة. لذلك ، يبدو أن افتراضك صحيح.

Answer 2

لقد وجدت هذا السؤال للتو لأنني كنت أسأل نفسي نفس الشيء. بالنسبة الى هذه المقالة من قبل أوراكل باحث ديفيد ديس, ، يبدو أن الجواب لا. هذا هو الجزء ذي الصلة من المقال:

إذا تم حظر الخيط في park() نحن نضمن ذلك بعد ذلك unpark() سوف يجعلها جاهزة. تطبيق قانوني تمامًا ولكنه منخفض الجودة park() و unpark() ستكون طرقًا فارغة ، حيث يتحول البرنامج إلى الغزل البسيط. في الواقع هذا هو اختبار litmus للتصحيح park()-unpark() الاستخدام.

فارغة park() و unpark() الأساليب لا تعطيك أي يحدث قبل ضمانات العلاقة ، لذلك لكي يكون برنامجك محمولًا بنسبة 100 ٪ ، يجب ألا تعتمد عليها.

ثم مرة أخرى ، Javadoc of Locksupport يقول:

تم تصميم هذه الطرق لاستخدامها كأدوات لإنشاء أدوات التزامن ذات المستوى الأعلى ، وهي ليست في حد ذاتها مفيدة لمعظم تطبيقات التحكم في التزامن. ال park تم تصميم الطريقة للاستخدام فقط في إنشاءات النموذج:

while (!canProceed()) { ... LockSupport.park(this); }

نظرًا لأنك يجب عليك التحقق بشكل صريح من بعض الحالات على أي حال ، والتي ستشمل إما volatile أو المتغيرات المتزامنة بشكل صحيح ، الضمانات الضعيفة لـ park() لا ينبغي أن تكون في الواقع مشكلة ، أليس كذلك؟

Answer 3

إذا لم يتم توثيقه على هذا النحو ، فلن تتمكن من الاعتماد عليها إنشاء A DELE قبل العلاقة.

على وجه التحديد locksupport.java في رمز النقاط الساخنة ببساطة يستدعي غير آمن. park و .unpark!

ال يحدث قبل ستأتي العلاقة عمومًا من زوج قراءة الكتابة على علامة حالة متقلبة أو شيء مشابه.

تذكر ، إذا لم يتم توثيقها على أنها إنشاء ملف يحدث قبل العلاقة إذن أنت يجب تعامل معها كما لو أنها لا يمكن أن تثبت أنه على نظامك المحدد. الأنظمة المستقبلية والتطبيقات قد لا. لقد تركوا أنفسهم تلك الحرية لسبب وجيه.