Question about synchronized

[Thomas G. Marshall]

John C. Bollinger coughed up:

....[rip]...

Yes. You should think of synchronization as protecting sections of code
-- either blocks or methods -- not objects.

Yes! And where were you when I was getting railed on for making such a
claim in september '04?





....[rip]...

 

[Chris Uppal]

Yes! And where were you when I was getting railed on for making such a
claim in september '04?

I also wondered if "John" is being spoofed, or possibly has been taken over by
mind-eating aliens ;-)

For the record: /I/ am still me, and so am unchanged in my opinion that talking
of "protecting sections of code" is badly misleading...

-- chris

 

[Thomas G. Marshall]

Chris Uppal coughed up:

I also wondered if "John" is being spoofed, or possibly has been taken
over
by mind-eating aliens ;-)

For the record: /I/ am still me, and so am unchanged in my opinion that
talking of "protecting sections of code" is badly misleading...

-- chris

{Grumble}. Stepping back and squinting, it all comes down to how far up or
down the abstraction ladder you want to go I suppose. "it's a car!" "it's
a pile of atoms" "what's the point in the atoms if it doesn't form the
car?" "how can you possibly have a car without the atoms?" (pun on atomic
not intended).


--
Having a dog that is a purebred does not qualify it for breeding. Dogs need
to have several generations of clearances for various illnesses before being
bred. If you are breeding dogs without taking care as to the genetic
quality
of the dog (again, being purebred is *not* enough), you are what is known as
a
"backyard breeder" and are part of the problem. Most of the congenital
problems of present day dogs are traceable directly to backyard breeding.
Spay or neuter your pet responsibly, and don't just think that you're
somehow
the exception and can breed a dog without taking the care described.

 

[John C. Bollinger]

John C. Bollinger coughed up:

...[rip]...

Yes. You should think of synchronization as protecting sections of code
-- either blocks or methods -- not objects.

Yes! And where were you when I was getting railed on for making such a
claim in september '04?

At lunch? The dentist's? Pining for the fjords?

 

[John C. Bollinger]

I also wondered if "John" is being spoofed, or possibly has been taken over by
mind-eating aliens ;-)

If I deny it will you believe me?

For the record: /I/ am still me, and so am unchanged in my opinion that talking
of "protecting sections of code" is badly misleading...

It looks like I really stepped in it. I think, however, that this
debate is more about terminology and personal mental models than it is
about conflicting understanding among us (Chris, Thomas, and me) of how
synchronization affects program behavior. The OP was clearly confused
about the implications of objects having associated monitors, and at
this point I predict that he will indeed have more success in
understanding the behavior of multithreaded programs if he focuses his
attention on which sections of his code need to be synchronized, on
which monitor. I think in any case that he has taken the point, which
is that locking an object's monitor does not prevent access to any
unsynchronized part of any object's behavior.

 

[Chris Uppal]

It looks like I really stepped in it. I think, however, that this
debate is more about terminology and personal mental models than it is
about conflicting understanding among us (Chris, Thomas, and me) of how
synchronization affects program behavior.

And also about what we feel can safely be left unsaid in a high-level
description. My object-centric viewpoint won't let me leave them out. (Not
trying to re-open the debate, just giving an example of what I mean).

-- chris

 

[Thomas G. Marshall]

Chris Uppal coughed up:

And also about what we feel can safely be left unsaid in a high-level
description. My object-centric viewpoint won't let me leave them out.
(Not
trying to re-open the debate, just giving an example of what I mean).

This has been fairly clear from you, and from Lee (to a huge extent ) as
well. Speaking as an off and on instructor, however, I've seen the higher
levels of object state and monitors slow down entirely the learning of
what's actually taking place. And this confusion will often last clear into
"senior engineer" land. Engineers will often just view synchronization as
some snake-oil magic. We've all seen this belief in synchronized magic
bullets. IMO, the way to solve this is to have the person focus on the
notion of /critical section/ first, and how the mutex works.

I've actually seen people suggest adding synchronization even when there is
no multithreading going on at all! I believe John C. Bollinger is right in
his assessment in this case as well: the OP needs to understand the
[slightly] lower level of what's going on, which he clearly doesn't.


--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln arg1
arg2" sets the arguments in the same order as "mv arg1 arg2". Existing file
argument to non-existing argument. And in fact, mv itself is implemented as
a
link followed by an unlink.

 

[Thomas G. Marshall]

John C. Bollinger coughed up:

John C. Bollinger coughed up:

...[rip]...

Yes. You should think of synchronization as protecting sections of code
-- either blocks or methods -- not objects.

Yes! And where were you when I was getting railed on for making such a
claim in september '04?

At lunch? The dentist's? Pining for the fjords?

Yeah, well, that's ok. There were well over 1300 posts in that thread, and
we wondered all over up down left and right. I shouldn't have contributed
here, but it may be too late.

Into the abyss.........


--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln arg1
arg2" sets the arguments in the same order as "mv arg1 arg2". Existing file
argument to non-existing argument. And in fact, mv itself is implemented as
a
link followed by an unlink.