Andrew John Hughes said the following on 03/13/09 10:13:
The rest of the code deals with allocating an ID to the
thread creating the LogRequest object and doesn't depend on the global
sequence number, so it doesn't matter if this is incremented by
another thread before the constructor completes.
Martin,
I was thinking we could special case the first thread and have it do the
initialization when "safe". (The first thread is the only case where it
appears to be its own parent, or in other words, where
Thread.currentThread()==this.
But let's not hijack this thread for this discussion.
On Thu, Mar 12, 2009 at 17:21, Andrew John Hughes
wrote:
> I agree. I also noticed that Thread uses a synchronised block to do
> the increment rather than the atomic. I don't know if there'd be any
> advantage to changing it or whether there is a good reason it was done
> like that.
java.lang.T
2009/3/13 Dalibor Topic :
> David M. Lloyd wrote:
>>
>>> It seems that the change would break serialization, by changing the type
>>> of a serialized field (in both classes) away from a primitive one. See
>>> http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html
>>>
>>> for det
David M. Lloyd wrote:
>
>> It seems that the change would break serialization, by changing the type
>> of a serialized field (in both classes) away from a primitive one. See
>> http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html
>>
>> for details.
>
> The fields are static
Opened as a BugZilla bug:
https://bugs.openjdk.java.net/show_bug.cgi?id=100021
- DML
On 03/12/2009 05:35 PM, David M. Lloyd wrote:
Switch to atomic ops for the various sequence numbers, as opposed to
synchronizing on the class object on every object construction.
2009/3/13 David M. Lloyd :
> On 03/12/2009 07:13 PM, Andrew John Hughes wrote:
>>
>> This is actually an interesting rare case where two atomic variables
>> can replace a synchronised block. Looking at the code, there seems to
>> be no issue with the thread being descheduled and then resumed durin
On 03/12/2009 07:13 PM, Andrew John Hughes wrote:
This is actually an interesting rare case where two atomic variables
can replace a synchronised block. Looking at the code, there seems to
be no issue with the thread being descheduled and then resumed during
the operation of this constructor. B
2009/3/13 David M. Lloyd :
> On 03/12/2009 07:01 PM, Dalibor Topic wrote:
>>
>> David M. Lloyd wrote:
>>>
>>> On 03/12/2009 05:41 PM, Mark Reinhold wrote:
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will eva
2009/3/12 Martin Buchholz :
> This looks fine, as long as there is no dependency of the implementation
> on the two atomic counters being incremented in concert, as seems likely.
>
> Martin
>
> On Thu, Mar 12, 2009 at 15:35, David M. Lloyd wrote:
>> Switch to atomic ops for the various sequence nu
I couldn't think of any situation where there would be.
- DML
On 03/12/2009 06:46 PM, Martin Buchholz wrote:
This looks fine, as long as there is no dependency of the implementation
on the two atomic counters being incremented in concert, as seems likely.
Martin
On Thu, Mar 12, 2009 at 15:35,
On 03/12/2009 07:01 PM, Dalibor Topic wrote:
David M. Lloyd wrote:
On 03/12/2009 05:41 PM, Mark Reinhold wrote:
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will evaluate
your patch sooner rather than later.
- Mark
[1
2009/3/13 Dalibor Topic :
> David M. Lloyd wrote:
>> On 03/12/2009 05:41 PM, Mark Reinhold wrote:
>>> You might want to have a look at the new contribution process [1].
>>> Using that will increase the probability that someone will evaluate
>>> your patch sooner rather than later.
>>>
>>> - Mark
>>
David M. Lloyd wrote:
> On 03/12/2009 05:41 PM, Mark Reinhold wrote:
>> You might want to have a look at the new contribution process [1].
>> Using that will increase the probability that someone will evaluate
>> your patch sooner rather than later.
>>
>> - Mark
>>
>> [1] http://openjdk.java.net/co
This looks fine, as long as there is no dependency of the implementation
on the two atomic counters being incremented in concert, as seems likely.
Martin
On Thu, Mar 12, 2009 at 15:35, David M. Lloyd wrote:
> Switch to atomic ops for the various sequence numbers, as opposed to
> synchronizing on
On 03/12/2009 05:41 PM, Mark Reinhold wrote:
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will evaluate
your patch sooner rather than later.
- Mark
[1] http://openjdk.java.net/contribute
Consider my post to be step 2
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will evaluate
your patch sooner rather than later.
- Mark
[1] http://openjdk.java.net/contribute
17 matches
Mail list logo
