[concurrency-interest] Relativity of guarantees provided by volatile

√iktor Ҡlang viktor.klang at gmail.com
Wed Aug 22 15:35:57 EDT 2012


On Wed, Aug 22, 2012 at 8:15 PM, Gregg Wonderly <gregg at cytetech.com> wrote:

> On 8/22/2012 12:18 PM, Zhong Yu wrote:
>
>> On Wed, Aug 22, 2012 at 1:39 AM, Marko Topolnik <mtopolnik at inge-mark.hr>
>> wrote:
>>
>>>
>>> On 22. kol. 2012., at 01:40, Boehm, Hans wrote:
>>>
>>>> From: Marko Topolnik [mailto:mtopolnik at inge-mark.hr**]
>>>>>
>>>>>  Similar to your concern that consecutive volatile writes can be
>>>>>> compressed into the last write, it also seems true that consecutive
>>>>>> volatile reads can be compressed into the first read - exactly the
>>>>>> kind of optimization to be disabled by C's volatile. It's
>>>>>> inconceivable that any JVM will do such optimization on volatile
>>>>>> reads, it'll break lots of programs, e.g. busy waits.
>>>>>>
>>>>>
>>>>> Actually there is already a provision in the JMM (in the original
>>>>> paper, at least) that prevents a busy-waiting loop whose condition
>>>>> involves a volatile read to forever read a stale value. There can be
>>>>> only a finite number of such read actions. But, this is a small
>>>>> consolation, really. Most code DOES make a difference between "eternity
>>>>> minus one" and "right now".
>>>>>
>>>>>  My recollection is that this is only sort of/mostly of true.  If your
>>>> entire program consists of
>>>>
>>>> Thread 1:
>>>> while (!flag) {}
>>>>
>>>> Thread 2:
>>>> flag = true;
>>>>
>>>> There is intentionally no requirement that thread 2 ever be scheduled.
>>>>  If it's not, that looks a lot like flag having been read once.  If, on the
>>>> other hand, thread 2 sets flag and then prints "Hello", and you see the
>>>> "Hello", then I believe you are correct that thread 1 must terminate.
>>>>
>>>
>>> If thread 2 never gets scheduled then the value of the flag is not stale
>>> (that's what I said---"read a stale value"). This JMM provision
>>>
>>
>> Can you give the reference to this provision? (I didn't see an
>> explicit one; though it's quite natural, since the set of actions
>> should be countable)
>>
>> precludes bunching together an infinite amount of busy-wait flag
>> checks, all reading the stale false value.
>>
>
> Java provides for no guarantees that the host operating system will
> actually, effectively (for you), schedule any thread other than the current
> one, with any reliability.  It just states when a thread is running, this
> is the behavior you will perceive based on the JLS and JMM.
>

Also, there is no way for the current Thread to know how much of cpu quanta
it has left. So one can never assume execution will be done.


>
> So, Thread.yield()'s necessity of use is unspecified.  But there were some
> early JVMs which did require the use of Thread.yield because the thread
> scheduling and/or os were not preemptive.
>
> Gregg
>
>
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>



-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120822/21d3abb5/attachment.html>


More information about the Concurrency-interest mailing list