Re: What's the connection between objects and threads?
On Tue, 20 May 2008 17:56:10 -0700, Szabolcs Ferenczi wrote:
On May 21, 2:26??am, I V <ivle...@gmail.com> wrote:
Again, the compiler can ensure that the shared state is only accessed
within a critical region (which, in this case, is equivalent to a block
containing the construction of the relevant synchronized<T> object).
But my proposed syntax can be implemented just as well with a library
solution as with a keyword based one, if the language provides certain
guarantees. So what's the difference?
It is not about syntax but first of all it is about semantics. However,
without syntax you cannot talk about semantics.
Sure; I was trying to show you that you could get identical semantics to
the ones in your example using the existing C++ syntax (clearly, you need
more semantics than the C++ standard currently specifies; but the point
is that you don't need any more syntax).
In your version `shared' and `synchronized' are keywords, aren't they?
They don't have to be, that's the point. They could be class templates.
If yes, you already introduced keywords for the language which the
compiler can recognise. How would you describe the semantics of these
keywords? What is the role of object `s'?
With your suggestion, you declare the shared int 'm', synchronize on that
variable 'm', and access the shared data through the object 'm'. In my
suggestion, you declare the shared int 'm' and synchronize on the
variable 'm', but you access the shared data through the variable 's'.
The object of type synchronized<T> provides access to shared data of type
T that was declared with shared<T>. When an object of type
synchronized<T> is created, it ensures (through whatever method - the
obvious one is a mutex) that any other attempt to created a
synchronized<T> based on the particular shared variable will block. When
the synchronized<T> is destroyed, it removes that restriction.
If not, it can really be implemented with a library solution but the
compiler will not be able to identify the block what you mean as the
Critical Region and hence it cannot ensure for you that the intended
shared variable is only accessed within Critical Region.
Sure it can. The point is that the object of type synchronized<T> is the
only way in which one can gain access to the shared data. Therefore,
anywhere in which an object of type synchronized<T> is in scope is a
critical region; any attempt to access the shared state without creating
a synchronized<T> object (and therefore a critical region) will cause a
compile error. For instance:
shared<int> i, j, k;
i = j + k;
wouldn't compile, whereas:
shared<int> i, j, k;
{
synchronized<int> s_i(i), s_j(j), s_k(k);
s_i = s_j + s_k
}
would.