postponed Initialization in multithreaded enviroment.

[George]

I am trying to implement postponed initialization (object is not initialize
till requested).

public class clsStore
{
volatile List<clsPictureGroup_lstPictureGroups = null;

public List<clsPictureGroupPictureGroups
{
get
{
if (_lstPictureGroups == null)
{
lock (this)
{
if (_lstPictureGroups == null)
_lstPictureGroups = LoadPictureGroup();
}
}
return _lstPictureGroups;
}
}
}

Obviously this code suppose to run in multithreaded enviroment in ASP.NET.
Anyone sees any problem in this code?
As far as i can see there is no 'race' condition here and code is safe.
Thanks
George.

[John Saunders]

"George" <no*****@comcast.netwrote in message
news:u7**************@TK2MSFTNGP06.phx.gbl...

I am trying to implement postponed initialization (object is not
initialize till requested).

public class clsStore
{
volatile List<clsPictureGroup_lstPictureGroups = null;

public List<clsPictureGroupPictureGroups
{
get
{
if (_lstPictureGroups == null)
{
lock (this)
{
if (_lstPictureGroups == null)
_lstPictureGroups = LoadPictureGroup();
}
}
return _lstPictureGroups;
}
}
}

Obviously this code suppose to run in multithreaded enviroment in ASP.NET.
Anyone sees any problem in this code?
As far as i can see there is no 'race' condition here and code is safe.

There are a few problems.

1) Best practice is to create a separate member to act as the lock variable:
private object _locker = new object()
2) The member need not be volatile - you are only going to change it while
it is locked, right?
3) You do not need to initialize it to null, as that is the default value.
This is not C or C++ - there is a specific default value for every type, so
there is no need to initialize something just to make sure you're not
accessing uninitialized data. There _is_ no uninitialized data.

The fourth is just a matter of style. Classes are not an unusual construct
in C#. In fact, they are the norm. It is really very redundant to prefix
every class with "cls". Similarly, do you really want to prefix all of your
lists with "lst"? You will learn more from hovering the mouse over the
member in the editor than by seeing "lst", which could mean any sort of list
(unless you restrict "lst" to be only List<T>).

--
John Saunders | MVP - Connected System Developer

[=?Utf-8?B?YnJ1Y2UgYmFya2Vy?=]

its not really threadsafe. you have a race condition on (_lstPictureGroups ==
null), as this is not an atomic operation (not threadsafe), nor is the
assignment. the hole is small and you would probably get away with it.

-- bruce (sqlwork.com)
"George" wrote:

I am trying to implement postponed initialization (object is not initialize
till requested).

public class clsStore
{
volatile List<clsPictureGroup_lstPictureGroups = null;

public List<clsPictureGroupPictureGroups
{
get
{
if (_lstPictureGroups == null)
{
lock (this)
{
if (_lstPictureGroups == null)
_lstPictureGroups = LoadPictureGroup();
}
}
return _lstPictureGroups;
}
}
}

Obviously this code suppose to run in multithreaded enviroment in ASP.NET.
Anyone sees any problem in this code?
As far as i can see there is no 'race' condition here and code is safe.
Thanks
George.

[John Saunders]

"bruce barker" <br*********@discussions.microsoft.comwrote in message
news:2D**********************************@microsof t.com...

its not really threadsafe. you have a race condition on (_lstPictureGroups
==
null), as this is not an atomic operation (not threadsafe), nor is the
assignment. the hole is small and you would probably get away with it.

Bruce, it is thread-safe, since he checks the value both before and after
the lock.
--
John Saunders | MVP - Connected System Developer

[George]

See inline...
"John Saunders" <[e-mail] in message
news:uo**************@TK2MSFTNGP04.phx.gbl...

"George" <no*****@comcast.netwrote in message
news:u7**************@TK2MSFTNGP06.phx.gbl...

>I am trying to implement postponed initialization (object is not
initialize till requested).

public class clsStore
{
volatile List<clsPictureGroup_lstPictureGroups = null;

public List<clsPictureGroupPictureGroups
{
get
{
if (_lstPictureGroups == null)
{
lock (this)
{
if (_lstPictureGroups == null)
_lstPictureGroups = LoadPictureGroup();
}
}
return _lstPictureGroups;
}
}
}

Obviously this code suppose to run in multithreaded enviroment in
ASP.NET.
Anyone sees any problem in this code?
As far as i can see there is no 'race' condition here and code is safe.

There are a few problems.

1) Best practice is to create a separate member to act as the lock
variable: private object _locker = new object()

I know it's best but only if you are locking (in my case clsStore) for any
other reason. If not, then i do not see any difference between lock(this) or
lock(_locker).

2) The member need not be volatile - you are only going to change it while
it is locked, right?

I think it needs to be.. I am afraid the compiler will optimize line #1 and
line #2. Is not what volatile for.... to prevent that kind of optimization.

1: if (_lstPictureGroups == null)
{
lock (this)
{
2: if (_lstPictureGroups == null)
_lstPictureGroups = LoadPictureGroup();

3) You do not need to initialize it to null, as that is the default value.
This is not C or C++ - there is a specific default value for every type,
so there is no need to initialize something just to make sure you're not
accessing uninitialized data. There _is_ no uninitialized data.

It's just my C++ experince playing here.... Sorry, I just feel bad if i do
not initalize variable specifically :)

>
The fourth is just a matter of style. Classes are not an unusual construct
in C#. In fact, they are the norm. It is really very redundant to prefix
every class with "cls". Similarly, do you really want to prefix all of
your lists with "lst"? You will learn more from hovering the mouse over
the member in the editor than by seeing "lst", which could mean any sort
of list (unless you restrict "lst" to be only List<T>).

Yea, I kind of used to that style... I like Hungarian notation. All my code
has lst...txt..chk...map
May be I am just an old school but I find it easier.
Thanks for your comments...
George.

[George]

I think I am ok with that line
if (_lstPictureGroups == null)

My only concern is if it allows dirty read.... Meaning that if
_lstPictureGroups has not been fully set and basically there is a point in
time when _lstPictureGroups returns some garbage.

What do you guys think? Valid concern?

Thanks
George.
"John Saunders" <[e-mail] in message
news:en**************@TK2MSFTNGP02.phx.gbl...

"bruce barker" <br*********@discussions.microsoft.comwrote in message
news:2D**********************************@microsof t.com...

>its not really threadsafe. you have a race condition on
(_lstPictureGroups ==
null), as this is not an atomic operation (not threadsafe), nor is the
assignment. the hole is small and you would probably get away with it.

Bruce, it is thread-safe, since he checks the value both before and after
the lock.
--
John Saunders | MVP - Connected System Developer

[John Saunders]

"George" <no*****@comcast.netwrote in message
news:uM**************@TK2MSFTNGP04.phx.gbl...

I think I am ok with that line
if (_lstPictureGroups == null)

My only concern is if it allows dirty read.... Meaning that if
_lstPictureGroups has not been fully set and basically there is a point in
time when _lstPictureGroups returns some garbage.

What do you guys think? Valid concern?

It's only set under lock, so I don't see that it's possible.
--
John Saunders | MVP - Connected System Developer

[George]

It's set under lock.
But read happens without any regard of "lock"
if (_lstPictureGroups == null) is done without lock attempt....
George.

"John Saunders" <[e-mail] in message
news:ud**************@TK2MSFTNGP02.phx.gbl...

"George" <no*****@comcast.netwrote in message
news:uM**************@TK2MSFTNGP04.phx.gbl...

>I think I am ok with that line
if (_lstPictureGroups == null)

My only concern is if it allows dirty read.... Meaning that if
_lstPictureGroups has not been fully set and basically there is a point
in time when _lstPictureGroups returns some garbage.

What do you guys think? Valid concern?

It's only set under lock, so I don't see that it's possible.
--
John Saunders | MVP - Connected System Developer

[John Saunders]

"George" <no*****@comcast.netwrote in message
news:#G**************@TK2MSFTNGP02.phx.gbl...

It's set under lock.
But read happens without any regard of "lock"
if (_lstPictureGroups == null) is done without lock attempt....

I'm very sure that checking a reference for null is an atomic operation in
..NET.

Also, note that he properly checks the reference twice - once before, and
once after taking out the lock. It is possible for multiple threads to see
that the field is null and attempt to acquire the lock. Only one of those
threads will acquire the lock and then find that the field is still null,
and set it to a non-null value. The other threads will acquire the lock, in
turn, and find that the field has already been set to a non-null value. They
will therefore not set it to a different non-null value.

Like the old saying, "measure twice, cut once", but this one is, "check
twice, set once".

--
John Saunders | MVP - Connected System Developer

[George]

>>I'm very sure that checking a reference for null is an atomic operation in

>>.NET.

I am inclined to that too.
Looks like my code is clear...:)
Thanks a lot for your comments guys..
George.
"John Saunders" <[e-mail] in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

"George" <no*****@comcast.netwrote in message
news:#G**************@TK2MSFTNGP02.phx.gbl...

>It's set under lock.
But read happens without any regard of "lock"
if (_lstPictureGroups == null) is done without lock attempt....

I'm very sure that checking a reference for null is an atomic operation in
.NET.

Also, note that he properly checks the reference twice - once before, and
once after taking out the lock. It is possible for multiple threads to see
that the field is null and attempt to acquire the lock. Only one of those
threads will acquire the lock and then find that the field is still null,
and set it to a non-null value. The other threads will acquire the lock,
in turn, and find that the field has already been set to a non-null value.
They will therefore not set it to a different non-null value.

Like the old saying, "measure twice, cut once", but this one is, "check
twice, set once".

--
John Saunders | MVP - Connected System Developer