Am I trapped over a pitfall (exposing static lock object)?

[Lothar Behrens]

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

 

[Arne Vajhøj]

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