[concurrency-interest] when is safe publication safe?

Joe Bowbeer joe.bowbeer at gmail.com
Sun Apr 25 19:26:39 EDT 2010


Jochen,

What you are describing seems like a caching problem as much as it is about
safe publication and/or dynamic languages.  The language runtime creates the
(immutable) instances and publishes them to the cache, right?  The
performance of the cache is the hot spot?

So are you using something like MapMaker to implement the cache?

http://code.google.com/p/google-collections/

What are you using to hold off a t2 when t1 is in the process of publishing
to the cache?  Some scheme involving a Future?

Joe

On Sun, Apr 25, 2010 at 8:48 AM, Jochen Theodorou wrote:

> Doug Lea wrote:
>
>> On 04/25/10 05:31, Jochen Theodorou wrote:
>>
>>> As a first step, consider exactly what effects/semantics you want
>>>> here, and the ways you intend people to be able to write conditionally
>>>> correct Groovy code.
>>>>
>>>
>>> People wouldn't have to write conditionally correct Groovy code. they
>>> would write normal code as they would in Java (Groovy and Java are very
>>> near).
>>>
>>
>> It seems implausible that you could do enough
>> analysis at load/run time to determine whether you need
>> full locking in the presence of multithreaded racy initialization
>> vs much cheaper release fences. This would require at least some
>> high-quality escape analysis. And the code generated
>> would differ both for the writing and reading callers.
>>
>
> maybe I did explain it not good. Let us assume I have the Groovy code:
>
> 1+1
>
> Then this is really something along the lines of:
>
> SBA.getMetaClassOf(1).invoke("plus",1)
>
> and SBA.getMetaClassOf(1) would return the meta class of Integer. Since
> this is purely a runtime construct, it does not exist until the first time
> this meta class is requested. So getMetaClassOf would be the place to
> initialize the meta class, that would register it in a global structure and
> on subsequent invocation use that cached meta class. If two threads execute
> the code above, then one would do the initialization, while the other has to
> wait. The waiting thread would then read the initialized global meta class.
> On subsequent invocations both threads would just read. Since changes of the
> meta class are rare, we would in 99% of all cases simply read the existing
> value. Since we have to be memory aware, these meta class can be unloaded at
> runtime too. They are SoftReferenced so it is done only if really needed.
> But rather than the normal change a reinitialization might be needed much
> more often.
>
> As you see the user code "1+1" does contain zero synchronization code. The
> memory barriers are all in the runtime. It is not that this cannot be solved
> by using what Java already has, it is that this is too expensive.
>
>
>  As I mentioned, an alternative is to lay down some rules.
>> If people stick to the rules they get consistent (in the sense
>> of data-race-free) executions, else they might not. And of
>> such rules, I think the ones that can apply here amount
>> to saying that other threads performing initializations cannot
>> trust any of their reads of the partially initialized object.
>> And further, they cannot leak refs to that object outside of the
>> group of initializer threads.
>>
>> This is not hugely different than the Swing threading rules
>> (http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html)
>> but applies only during initialization.
>>
>
> but unlike what the above may suggest there is no single initialization
> phase. The meta classes are created on demand. We cannot know beforehand
> which meta classes are needed and doing them all before starting would
> increase the startup time big times.
>
> If there were of course a way to recognize a partially initialized object I
> could maybe think of something... but is there a reliable one?
>
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100425/3d7a1e04/attachment.html>


More information about the Concurrency-interest mailing list