Thread synchronization

Thomas G. Marshall wrote:
>
> YES. But I stress the /synchronized(this)/ idiom because interesting things
> happen when the /synchronized method()/ idiom is used:
>
> 1. The developer is far less likely to shift over to
> using a different lock should the need arise. He
> feels "locked in" to using the current object
> instance.
>

Also, I've seen a lot of developers (esp. fresh out of school) who don't even
know about synchronized blocks (as opposed to synchronized methods) because
(almost) all code they have seen is where methods are declared as synchronized.
So in my opinion, schools ought to first teach synchronization following the
synchronized(object) {... } paradigm, and then go on to explain the "shortcut"
form available in the special situation where the monitor object happens to be
"this" and the critical section of the code happens to be an entire method body.

BK

Babu Kalakrishnan coughed up:
> Thomas G. Marshall wrote:
>>
>> YES. But I stress the /synchronized(this)/ idiom because
>> interesting things happen when the /synchronized method()/ idiom is
>> used:
>>
>> 1. The developer is far less likely to shift over to
>> using a different lock should the need arise. He
>> feels "locked in" to using the current object
>> instance.
>>
>
> Also, I've seen a lot of developers (esp. fresh out of school) who
> don't even know about synchronized blocks (as opposed to synchronized
> methods) because (almost) all code they have seen is where methods
> are declared as synchronized. So in my opinion, schools ought to
> first teach synchronization following the synchronized(object) {... }
> paradigm, and then go on to explain the "shortcut" form available in
> the special situation where the monitor object happens to be "this"
> and the critical section of the code happens to be an entire method
> body.


YES.



--
"Gentlemen, you can't fight in here! This is the War Room!"

Thomas G. Marshall wrote:
>
> Lee Fesperman coughed up:
> > Simply put: if you are not protecting data then synchronization is
> > meaningless. It's not doing anything. There is no useful case where
> > this is not true.
>
> Ok. And if you are not protecting the program at large, then
> synchronization is meaningless. There is no useful case where this is not
> true. Keep wandering up, like I pointed out elsethread.

Asinine. You are confusing the technique with its purpose. Synchronization is a
technique used for the purpose of restricting access to shared state.

> Larger contexts always exist. But there are /lines of code/ in
> synchronization blocks and methods. Saying that you are protecting an
> object is of no good in teaching someone how the particular /lines of code/
> might need be atomic to an algorithm.

You are misleading your students if you refuse to tell them that synchronization is used
to restrict access to shared state (including the state of external resources.)

In fact, you haven't given a useful example where it is not true. Your one vague example
of an algorithm that can't be interrupted yet doesn't have shared state doesn't hold
water. Provide more details to support your example.

> And it is those lines of code /within/ such synchronization structures that
> are protected. Lines exterior to those simply are not.

What is a synchronization structure? Your statement is vague and sounds wrong.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

Chris Uppal wrote:
>
> Lee Fesperman wrote:
>
> > > Now in some cases, the state that needs to be protected will be either
> > > distributed across more than one object, or be less than the entire
> > > state of an object. Such cases are rare -- as you'd expect because the
> > > object is (or
> > > should be) expressing a semantically coherent unit of state, and the
> > > protection
> > > will normally be expected to follow the same boundaries, precisely
> > > /because/ it
> > > is protecting semantic coherence. Still, such cases do occur, and in
> > > those
> > > cases, and /only/ in those cases, your more "advanced" technique of
> > > using a
> > > lock object is appropriate.
> >
> > Not quite. There are other cases where a separate 'monitor' is
> > appropriate, but I agree that it should be subject object in most cases.
>
> Well, the data to be protected is either a subset of the state of one object,
> the entire state of one object, or spread across more than one object -- it's
> not immediately obvious what your fourth possibility is ?

Your paragraph was somewhat vague, but here goes...

You list 'some' cases (2 actually):

1) spread across more than one object,
2) subset of state of one object.

You then state that *only* in those cases is a lock object appropriate.

You also list the 'normal' case:

3) entire state of one object.

You imply that this case would use the object as the monitor.

This is a fourth case:

4) entire state of one object but using a separate monitor to protect its state.

You left this one out of your *only* ***ertion.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

Lee Fesperman coughed up:
> Thomas G. Marshall wrote:
>>
>> Lee Fesperman coughed up:
>>> Simply put: if you are not protecting data then synchronization is
>>> meaningless. It's not doing anything. There is no useful case where
>>> this is not true.
>>
>> Ok. And if you are not protecting the program at large, then
>> synchronization is meaningless. There is no useful case where this
>> is not true. Keep wandering up, like I pointed out elsethread.
>
> Asinine.

Careful. You want people to ignore you? Then go and throw unwarranted
insults like that around some more. I don't remember saying that your
notions were asinine.


> You are confusing the technique with its purpose.

Actually, I was pointing out that /you/ were.


> Synchronization is a technique used for the purpose of restricting
> access to shared state.

Nail down any purpose you like. It still comes down to making sure that
lines of code are protected from concurrent execution.


>> Larger contexts always exist. But there are /lines of code/ in
>> synchronization blocks and methods. Saying that you are protecting
>> an object is of no good in teaching someone how the particular
>> /lines of code/ might need be atomic to an algorithm.
>
> You are misleading your students if you refuse to tell them that
> synchronization is used to restrict access to shared state (including
> the state of external resources.)

You are misleading everyone you talk to if you try to convince them that the
lines within the synchronization blocks /aren't/ what's important. Your
explanations simply do /not/ help a student to understand where and how to
apply synchronization, and why entire methods do not need to be
synchronized, for example.

> In fact, you haven't given a useful example where it is not true. Your
> one vague example of an algorithm that can't be interrupted yet
> doesn't have shared state doesn't hold water. Provide more details
> to support your example.

Provide /one/ detail as to why it doesn't hold water.


>> And it is those lines of code /within/ such synchronization
>> structures that are protected. Lines exterior to those simply are
>> not.
>
> What is a synchronization structure? Your statement is vague and
> sounds wrong.

You never heard of a synchronization block? That's not a synchronization
structure?



--
Whyowhydidn'tsunmakejavarequireanuppercaseletterto startcl***names....

Thomas G. Marshall wrote:
>
> Lee Fesperman coughed up:
> > Thomas G. Marshall wrote:
> >>
> >> Lee Fesperman coughed up:
> >>> Simply put: if you are not protecting data then synchronization is
> >>> meaningless. It's not doing anything. There is no useful case where
> >>> this is not true.
> >>
> >> Ok. And if you are not protecting the program at large, then
> >> synchronization is meaningless. There is no useful case where this
> >> is not true. Keep wandering up, like I pointed out elsethread.
> >
> > Asinine.
>
> Careful. You want people to ignore you? Then go and throw unwarranted
> insults like that around some more. I don't remember saying that your
> notions were asinine.

You twisted my words to mock them as foolish. You didn't add anything substantive to the
discussion.

> > You are confusing the technique with its purpose.
>
> Actually, I was pointing out that /you/ were.

More word play? You're saying that protecting state is a technique used for the purpose
of synchronizing threads?

> Nail down any purpose you like. It still comes down to making sure that
> lines of code are protected from concurrent execution.

Yep, I realize that nothing anyone can say will change your mind. OTOH, all it would
take to convince me is a useful case where synchronization is needed except for
protecting external state ... you may need to provide details, though.

> >> ... Saying that you are protecting
> >> an object is of no good in teaching someone how the particular
> >> /lines of code/ might need be atomic to an algorithm.
> >
> > You are misleading your students if you refuse to tell them that
> > synchronization is used to restrict access to shared state (including
> > the state of external resources.)
>
> You are misleading everyone you talk to if you try to convince them that the
> lines within the synchronization blocks /aren't/ what's important.

Again, you are twisting my words for no reasonable purpose. I haven't said that
synchronization is unimportant in protecting state ... it is a *very* important
technique. You're not just saying that mentioning state is unimportant in discussing
synchronization but that it would do no good.

> Your explanations simply do /not/ help a student to understand where and how to
> apply synchronization, and why entire methods do not need to be
> synchronized, for example.

I'm explaining why you use synchronization which naturally leads to where and how to
apply it. If you don't know the purpose of synchronizing, you won't know where to apply
it. Avoiding concurrent execution is too vague a goal. Why do you need to avoid
concurrent execution?

> > In fact, you haven't given a useful example where it is not true. Your
> > one vague example of an algorithm that can't be interrupted yet
> > doesn't have shared state doesn't hold water. Provide more details
> > to support your example.
>
> Provide /one/ detail as to why it doesn't hold water.

You've refused to provide details. That makes it rather difficult to pick one.
Nevertheless, I will respond ---

If you can't interrupt (delay) this thread and the thread doesn't affect external state,
who would ever know if you did interrupt it? If it has no effects, interrupting it would
have no effect.

> >> And it is those lines of code /within/ such synchronization
> >> structures that are protected. Lines exterior to those simply are
> >> not.
> >
> > What is a synchronization structure? Your statement is vague and
> > sounds wrong.
>
> You never heard of a synchronization block? That's not a synchronization
> structure?

Ok. You meant synchronization block. Perhaps you could have said 'synchronization
control structure'. Further imprecision in your statements made it necessary to clarify.

To continue: By /within/, do you mean --- lines of code textually inside the braces of a
synchronization block (or synchronized method)?

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)