The synchronized statement makes sure that one block of code is not executed by
more than one thread at the same time. Is there any way to extend this to two
blocks? For example, make sure that at any one time only Foo() or Bar() is
executing but not both.
int A;
Foo()
{
A = 1;
DoSomthingWithA();
}
Bar()
{
A = 2;
DoSomthingElseWithA()
}
I can see use for this in a collection object to make sure that only one thread
is changing data at any given time.
Another closely linked idea would be to have several levels of protection, e.g.
"BCS" <BCS_member pathlink.com> wrote in message
news:dbbso6$275s$1 digitaldaemon.com...
The synchronized statement makes sure that one block of code is not
executed by
more than one thread at the same time. Is there any way to extend this to
two
blocks? For example, make sure that at any one time only Foo() or Bar() is
executing but not both.
int A;
Foo()
{
A = 1;
DoSomthingWithA();
}
Bar()
{
A = 2;
DoSomthingElseWithA()
}
int A;
Object lock;
static this() {lock = new Object;}
Foo()
{
synchronized(lock) {
A = 1;
DoSomthingWithA();
}
}
Bar()
{
synchronized(lock) {
A = 2;
DoSomthingElseWithA()
}
}
I can see use for this in a collection object to make sure that only one
thread
is changing data at any given time.
Another closely linked idea would be to have several levels of protection,
e.g.
any number of "low" block can execute but only if no "high" block are
running or
waiting.
I'm not sure what you mean here.
One other thought on sync blocks, how about an else that gets run instead
of
just blocking.
Do you mean it gets repeatedly run after trying to acquire the lock? For
fancy behavior like that you can use the port of the Java concurrent package
at http://home.comcast.net/~benhinkle/locks/locks.html. The Lock interface
supports a "tryLock" method with optional timeout.
In article <dbc2u5$2b7o$1 digitaldaemon.com>, Ben Hinkle says...
int A;
Object lock;
static this() {lock = new Object;}
Foo()
{
synchronized(lock) {
A = 1;
DoSomthingWithA();
}
}
Bar()
{
synchronized(lock) {
A = 2;
DoSomthingElseWithA()
}
}
I haven’t tried that, but from what the reference says ("synchronized allows
only one thread at a time to execute [the] Statement.") I would expect that two
different synchronized blocks could both be executed with the same object at the
same time (if this is not the case, than the reference is ambiguous or wrong).
I can see use for this in a collection object to make sure that only one
thread is changing data at any given time.
Another closely linked idea would be to have several levels of protection,
e.g. any number of "low" block can execute but only if no "high" block are
running or waiting.
I'm not sure what you mean here.
I’m thinking of a sort of read-only vs. write access scenario. Any number of
reads can safely happen at the same time as long as no writes are happening but
only one write can safely happen at any given time. This might be expressed
explicitly as read vs. write or maybe in some other from.
One other thought on sync blocks, how about an else that gets run instead
of
just blocking.
Do you mean it gets repeatedly run after trying to acquire the lock? For
fancy behavior like that you can use the port of the Java concurrent package
at http://home.comcast.net/~benhinkle/locks/locks.html. The Lock interface
supports a "tryLock" method with optional timeout.
Actually, that looks a lot like what I was thinking of. I was just suggesting
that kind of thing (or some of it) be made part of the language. Specifically, I
was thinking of a non-blocking synchronized, e.g. "If you can get access to this
stuff, run this code, else skip it (or run this other code)"
synchronized(A)
{
//do somthing if A isn't in use
}
else
{
//do something else if A is in use
}
This would allow many other construct, a retry with timeout block could be done
like this
do
synchronized(A)
{
//do something
break;
}
else{}
while(NotTimeOut());
"BCS" <BCS_member pathlink.com> wrote in message
news:dbgp3v$9ri$1 digitaldaemon.com...
In article <dbc2u5$2b7o$1 digitaldaemon.com>, Ben Hinkle says...
int A;
Object lock;
static this() {lock = new Object;}
Foo()
{
synchronized(lock) {
A = 1;
DoSomthingWithA();
}
}
Bar()
{
synchronized(lock) {
A = 2;
DoSomthingElseWithA()
}
}
I haven't tried that, but from what the reference says ("synchronized
allows
only one thread at a time to execute [the] Statement.") I would expect
that two
different synchronized blocks could both be executed with the same object
at the
same time (if this is not the case, than the reference is ambiguous or
wrong).
The next sentance in the doc talks about "synchronized(Expression) {...}".
To see why it works only one thread at a time can hold an Object's lock. So
to make any number of blocks execute one at a time have each one grab a
shared Object's lock.
In article <dbgqi0$auh$1 digitaldaemon.com>, Ben Hinkle says...
I haven't tried that, but from what the reference says ("synchronized
allows only one thread at a time to execute [the] Statement.")
..
The next sentance in the doc talks about "synchronized(Expression) {...}".
Quote the next sentance:
"... allows only one thread at a time to use that Object to execute THE
Statement."
Note emphasis.
Again the reference is ambiguous or wrong. It seems that, according to the
reference, the synchronized(Exp) form of the synchronized statement is
block-centric not object-centric (the lock is on the block with respect to the
object not on the object it’s self).
If I am wrong than the reference should read "... execute _any synchronized_
Statement."
"BCS" <BCS_member pathlink.com> wrote in message
news:dbgs5q$cd6$1 digitaldaemon.com...
In article <dbgqi0$auh$1 digitaldaemon.com>, Ben Hinkle says...
I haven't tried that, but from what the reference says ("synchronized
allows only one thread at a time to execute [the] Statement.")
..
The next sentance in the doc talks about "synchronized(Expression) {...}".
Quote the next sentance:
"... allows only one thread at a time to use that Object to execute THE
Statement."
Note emphasis.
Again the reference is ambiguous or wrong. It seems that, according to the
reference, the synchronized(Exp) form of the synchronized statement is
block-centric not object-centric (the lock is on the block with respect to
the
object not on the object it's self).
If I am wrong than the reference should read "... execute _any
synchronized_
Statement."
Sure - I agree "any" is more clear than "the". To make it even more clear
the phrasing could probably be expand to something like "allows only one
thread at a time to use that Object to execute any synchronized statement or
synchronized object method that synchronize on that Object".
But then I'm no writer :-P
"Ben Hinkle" <bhinkle mathworks.com>