T
Thomas G. Marshall
xarax coughed up:
You are protected from concurrent execution of that code. Code itself is
always there, sure. Precisely /what/ code that is protected by mutex is the
issue.
It's all about who is holding the lock. And determining whether or not your
synchronized block is actually working or not depends upon what you have
placed within it.
Again, the term "protecting" is causing a terminology collision of sorts.
When I say that the code is being protected, what I'm saying (and have said
over and over) is that multiple executions of the code are prevented from
running concurrently (when done right).
For example, if you thought that I was saying that the code itself was
mutable and itself needed protection from alteration as such, then you'd be
right in correcting me.
But to understand what is happening, you need to be aware that all
synchronization and hence protection of the data, depends entirely on what
is placed within the synchronization blocks. It is all about the code: it
is all about what code is protected from concurrent execution.
Sure and how is this accomplished? By carefully governing exactly /what/
code is placed under mutex protection.
Again, terminology collision (of sorts). I think we've collided enough for
one week.
"Thomas G. Marshall"
It is incorrect to think of synchronization as
protecting "code". It protects data. If there
were no code, there would be no processing and
no need for computers. Code is a "given".
You are protected from concurrent execution of that code. Code itself is
always there, sure. Precisely /what/ code that is protected by mutex is the
issue.
public class Fubar
{
protected int gonk;
public synchronized void snafu()
{
gonk++;
}
public synchronized void gorko()
{
gonk--;
}
}
Will the "synchronized" keyword prevent multiple
threads from concurrently executing the code? Say,
thread#1 calls snafu() and thread#2 calls gorko().
The answer is, "it depends". Maybe yes, maybe
no. Why? Because snafu() and gorko() are instance
methods, and the synchronization depends on which
instance each thread is referring to at the time
the method is called. it's all about the data, not
about the code.
It's all about who is holding the lock. And determining whether or not your
synchronized block is actually working or not depends upon what you have
placed within it.
Again, the term "protecting" is causing a terminology collision of sorts.
When I say that the code is being protected, what I'm saying (and have said
over and over) is that multiple executions of the code are prevented from
running concurrently (when done right).
For example, if you thought that I was saying that the code itself was
mutable and itself needed protection from alteration as such, then you'd be
right in correcting me.
But to understand what is happening, you need to be aware that all
synchronization and hence protection of the data, depends entirely on what
is placed within the synchronization blocks. It is all about the code: it
is all about what code is protected from concurrent execution.
Another way to describe it is synchronization
governs access to a resource. Data in memory can
be a resource. Files on a harddrive can be a
resource. There are synchronization mechanisms
to ensure the consistency of data and proper
access to resources. Any such synch mechanism
is a "protocol" that must be observed by all
threads that access the *same* resource. With
proper design and implementation, the resource
is protected from corruption.
Sure and how is this accomplished? By carefully governing exactly /what/
code is placed under mutex protection.
mutex protects data, not code.
Again, terminology collision (of sorts). I think we've collided enough for
one week.