Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > postponed Initialization in multithreaded enviroment.

Reply
Thread Tools

postponed Initialization in multithreaded enviroment.

 
 
George
Guest
Posts: n/a
 
      10-27-2008
I am trying to implement postponed initialization (object is not initialize
till requested).

public class clsStore
{
volatile List<clsPictureGroup> _lstPictureGroups = null;

public List<clsPictureGroup> PictureGroups
{
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.

 
Reply With Quote
 
 
 
 
bruce barker
Guest
Posts: n/a
 
      10-27-2008
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<clsPictureGroup> PictureGroups
> {
> 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.
>
>

 
Reply With Quote
 
 
 
 
John Saunders
Guest
Posts: n/a
 
      10-27-2008
"George" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I am trying to implement postponed initialization (object is not
> initialize till requested).
>
> public class clsStore
> {
> volatile List<clsPictureGroup> _lstPictureGroups = null;
>
> public List<clsPictureGroup> PictureGroups
> {
> 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

 
Reply With Quote
 
John Saunders
Guest
Posts: n/a
 
      10-27-2008
"bruce barker" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

 
Reply With Quote
 
George
Guest
Posts: n/a
 
      10-27-2008
See inline...


"John Saunders" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "George" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> I am trying to implement postponed initialization (object is not
>> initialize till requested).
>>
>> public class clsStore
>> {
>> volatile List<clsPictureGroup> _lstPictureGroups = null;
>>
>> public List<clsPictureGroup> PictureGroups
>> {
>> 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.


 
Reply With Quote
 
George
Guest
Posts: n/a
 
      10-27-2008
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 Removed)> wrote in message
news:(E-Mail Removed)...
> "bruce barker" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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


 
Reply With Quote
 
John Saunders
Guest
Posts: n/a
 
      10-27-2008
"George" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

 
Reply With Quote
 
George
Guest
Posts: n/a
 
      10-27-2008
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 Removed)> wrote in message
news:(E-Mail Removed)...
> "George" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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


 
Reply With Quote
 
John Saunders
Guest
Posts: n/a
 
      10-27-2008
"George" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> 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

 
Reply With Quote
 
George
Guest
Posts: n/a
 
      10-27-2008
>>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 Removed)> wrote in message
news:%(E-Mail Removed)...
> "George" <(E-Mail Removed)> wrote in message
> news:#(E-Mail Removed)...
>> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Microcosmos Postponed Pat DVD Video 0 02-21-2004 09:57 PM
New Releases: Space Camp, Take This Job, Schindler's List postponed: Updated complete downloadable R1 DVD DB & info list Doug MacLean DVD Video 0 12-16-2003 05:45 AM
Walt Disney Treasures Wave 3 Postponed to 5/4/04 CHL DVD Video 0 11-13-2003 07:00 PM
Popeye Postponed? \Mighty\ Mike Blues DVD Video 8 07-07-2003 09:02 AM
Re: Popeye Postponed? Vlvetmorning98 DVD Video 0 06-28-2003 07:54 PM



Advertisments