Hi,

I have a class that uses a static lock object like this:

public class WSClientAgent
{
static object lockUpdateBunchOfData = "lock";

public object LockUpdateBunchOfData
{
get { return WSClientAgent.lockUpdateBunchOfData; }
set { WSClientAgent.lockUpdateBunchOfData = value; }
}

// ....
}

Internally I double checked that all thread relevant code uses a lock
statement. To ensure all stuff uses the correct locking, I have
exposed the static lock as an attribute.

But it seems that I still get errors that probably rooted to a missing
lock anywhere, or a pitfall with the above code.

Is there anything how I have solved my lock issues?

I am using a object relational mapper (database classes) that causing
any seldom problems. Some external code uses the exposed lock to also
synchronize the database access. That's why I have exposed it. Also I
haven't yet put all ORM related code inside the class that runs the
thread to avoid exposing.

It is merely impossible to do so as I would wrap an ORM :-)

It is a bit wired, as it is too seldom :-)


Thanks,

Lothar

On 6/6/2011 6:32 AM, Lothar Behrens wrote:
> I have a class that uses a static lock object like this:
>
> public class WSClientAgent
> {
> static object lockUpdateBunchOfData = "lock";
>
> public object LockUpdateBunchOfData
> {
> get { return WSClientAgent.lockUpdateBunchOfData; }
> set { WSClientAgent.lockUpdateBunchOfData = value; }
> }
>
> // ....
> }
>
> Internally I double checked that all thread relevant code uses a lock
> statement. To ensure all stuff uses the correct locking, I have
> exposed the static lock as an attribute.
>
> But it seems that I still get errors that probably rooted to a missing
> lock anywhere, or a pitfall with the above code.
>
> Is there anything how I have solved my lock issues?

Depending on whether the resource you want to protect is really
single or not then either:
- drop set
- make field non static
or:
- drop set
- make field non static
- make class a singleton

> I am using a object relational mapper (database classes) that causing
> any seldom problems. Some external code uses the exposed lock to also
> synchronize the database access. That's why I have exposed it. Also I
> haven't yet put all ORM related code inside the class that runs the
> thread to avoid exposing.
>
> It is merely impossible to do so as I would wrap an ORM :-)

Usually an ORM should not require this type of synchronization. Just
setting the appropriate transaction isolation level should be
sufficient.

> It is a bit wired, as it is too seldom :-)

That is often the case with concurrency problems.

Arne