Declaritive syncronization thoughts...

  • Thread starter Thread starter William Stacey [MVP]
  • Start date Start date
W

William Stacey [MVP]

What if we had some kind on declarative synchronization where you could
declare, in declaration section, different lock sets for your invariant?
Something like:

public class MyClass
{
lock(sync1) // All three vars protected by same lock declaratively
(via internal object named sync1)..
{
private int counter1;
private int counter2;
private object obj;
}
lock(sync2) // These vars protected by a different lock and atomic
together.
{
private int someother;
private string desc;
}
private readonly string id = "123"; // no lock required.

public MyClass() {}

public string Name
{
get{ return name;}
set{ name = value;}
}
public int Counter1
{
get { return counter1; }
set { counter1 = value; }
}
}

Now you don't need lock blocks all over the place, but still get same
locking semantics when compiled. Also, I think this would help write better
code as you define your locking first based on your data (i.e. invariant
contract) and you can't forget to lock something and it reduces clutter and
number of lines you need to write. Maybe they could handle rw locks same
kind of way. Other ideas?
 
William Stacey said:
What if we had some kind on declarative synchronization where you could
declare, in declaration section, different lock sets for your invariant?
Something like:

<snip code>

Now you don't need lock blocks all over the place, but still get same
locking semantics when compiled. Also, I think this would help write better
code as you define your locking first based on your data (i.e. invariant
contract) and you can't forget to lock something and it reduces clutter and
number of lines you need to write. Maybe they could handle rw locks same
kind of way. Other ideas?
Click to expand...

Isn't this kinda like the synchronized keyword in Java? Wouldn't you just
have a
new synchronized keyword for properties or maybe attributes?

[Lock(sync2)]
public int Counter1{ get; set; }

-c
 
Kinda. But this would be a bit different. That protects the whole method.
This would protect any access to any of the fields inside the declaration
regardless of where they are referenced inside the class. The attribute
itself is on target with what I was thinking however.

--
William Stacey, MVP

Chad Myers said:
William Stacey said:
What if we had some kind on declarative synchronization where you could
declare, in declaration section, different lock sets for your invariant?
Something like:

<snip code>

Now you don't need lock blocks all over the place, but still get same
locking semantics when compiled. Also, I think this would help write better
code as you define your locking first based on your data (i.e. invariant
contract) and you can't forget to lock something and it reduces clutter and
number of lines you need to write. Maybe they could handle rw locks same
kind of way. Other ideas?
Click to expand...

Isn't this kinda like the synchronized keyword in Java? Wouldn't you just
have a
new synchronized keyword for properties or maybe attributes?

[Lock(sync2)]
public int Counter1{ get; set; }

-c
Click to expand...
 
Now you don't need lock blocks all over the place, but still get same
locking semantics when compiled. Also, I think this would help write
better
code as you define your locking first based on your data (i.e. invariant
contract) and you can't forget to lock something and it reduces clutter
and
number of lines you need to write. Maybe they could handle rw locks same
kind of way. Other ideas?
Click to expand...

One problem that comes to mind is how do you lock for access over several
fields? Say you need to increment counter1 and counter2 without releasing
sync1?
 
Hi William,

Sorry for my ignorance. I haven't seen this before. Generally we use lock
statement to protect shared resources in code block. I don't know what's
the effect if we lock the declaration.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
I was thinking about that issue as well. I think maybe their are two
approaches - the high road and low road.

High Road Solution:
Compiler and runtime together use the declarations and understand what needs
to be locked and how to write the code such that it does the right thing
based on meta data and some sophisticated logic (I would guess).

Low Road Solution:
The attributes verify during compile time that all said fields are accessed
in a locked context and flag compile errors if not. That alone would be a
big check I would think. It could also check that all vars in a "LockSet"
are accessed inside the same lock if they are read or written in the same
method. I ~think that all could be done just at compile time.
 
William Stacey said:
I was thinking about that issue as well. I think maybe their are two
approaches - the high road and low road.

High Road Solution:
Compiler and runtime together use the declarations and understand what
needs
to be locked and how to write the code such that it does the right thing
based on meta data and some sophisticated logic (I would guess).

Low Road Solution:
The attributes verify during compile time that all said fields are
accessed
in a locked context and flag compile errors if not. That alone would be a
big check I would think. It could also check that all vars in a "LockSet"
are accessed inside the same lock if they are read or written in the same
method. I ~think that all could be done just at compile time.
Click to expand...

Hrmm, I like the idea of declarativly defining lock sets. Even if it doesn't
automate anything it may well go a *long* way towards helping locking the
right things(even if it doesn't help much with lock acquisition order, ;).
Just being able to force locked(or interlocked) access may be a big boon.

I don't know how to do it, I certaily don't like attributes(IMHO, if a
feature *has* to use attributes, the feature is bad). Dreaming up syntax
would be the difficult part...
 
Kevin Yu said:
Sorry for my ignorance. I haven't seen this before. Generally we use lock
statement to protect shared resources in code block. I don't know what's
the effect if we lock the declaration.
Click to expand...

It's a feature suggestion - it clearly doesn't compile at the moment.
 
Thanks Jon,

Hi William,

If you have good suggestions that will make our future products better,
please feel free to send emails to (e-mail address removed) directly. Your
suggestions will be highly appreciated. Thank you!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Back
Top