lock file in ASP.NET

[WingSiu]

I am writing a Logging util for my ASP.NET application.
I am facing mulit process problem.

I developed a class LogFactory, and have a method called Get_Logger to
create a FileLogger, which will write text into a text file.

// sample code

FileLogger logger = LogFactory.Get_Logger();
logger.Log("Message here");
logger = null;

I read a lot of example that when we face the mulit process problem, we can
use the keyword "lock" to solve the problem
// example
File logger logger = LogFactory.Get_Logger();
lock (typeof (logger))
{
log.Log("Message here");
}
logger = null;

although a lot of article said that DONT use lock(typeof(logger)) because it
is a slow process and it will lock all objects, which in the same
application, and used in other process. However, I think in my case, I can
use typeof(logger) because I am try to write the message in a single text
file, no matter which process a instancing the logger object, I only need to
lock the text file, write text, release it and then other process repeat the
same step, right?

So my code is correct?? or any other better solution? Thanks

 

[Andrew Faust]

Nothing wrong with using Lock. Especially when you are using it for as
minimal of sections of code as possible. However, there are two things I'd
recommend changing. First, use lock(typeof(FileLogger)) calling typeof on
an actual object instead of a type name should throw a compiler error.
Second, I would move the lock within the Log method itself. If you need the
operation to always be threadsafe then the operation itself should be
responsible to ensure that it is. As you have it written now, you have no
guarantee of thread safety. If you forget to lock even one call anywhere to
the log method you could have issues.

 

[WingSiu]

Hi Andrew

After I read some website, now the code is changed like as follow

inside FileLogger,

private static readonly object = new object();

public void Log()
{
lock (object)
{
WriteLogToTextFile();
}
}

I am not sure why using static, but they always said lock a static object
should be better than lock a type.

Thanks

Nothing wrong with using Lock. Especially when you are using it for as
minimal of sections of code as possible. However, there are two things I'd
recommend changing. First, use lock(typeof(FileLogger)) calling typeof on
an actual object instead of a type name should throw a compiler error.
Second, I would move the lock within the Log method itself. If you need
the operation to always be threadsafe then the operation itself should be
responsible to ensure that it is. As you have it written now, you have no
guarantee of thread safety. If you forget to lock even one call anywhere
to the log method you could have issues.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

I am writing a Logging util for my ASP.NET application.
I am facing mulit process problem.

I developed a class LogFactory, and have a method called Get_Logger to
create a FileLogger, which will write text into a text file.

// sample code

FileLogger logger = LogFactory.Get_Logger();
logger.Log("Message here");
logger = null;

I read a lot of example that when we face the mulit process problem, we
can use the keyword "lock" to solve the problem
// example
File logger logger = LogFactory.Get_Logger();
lock (typeof (logger))
{
log.Log("Message here");
}
logger = null;

although a lot of article said that DONT use lock(typeof(logger)) because
it is a slow process and it will lock all objects, which in the same
application, and used in other process. However, I think in my case, I
can use typeof(logger) because I am try to write the message in a single
text file, no matter which process a instancing the logger object, I only
need to lock the text file, write text, release it and then other process
repeat the same step, right?

So my code is correct?? or any other better solution? Thanks

 

[Andrew Faust]

Locking on a static object will work fine in your situation. The way lock
works is by using whatever is in the lock() parameter as a key for that
code block. .Net differentiates between actual instances of objects. Thus
if you need a class wide lock you have three options. Lock on a static
object, lock on the actual class itself typeof(ClassName) or lock on an
instance of an object that you pass around to all the classes that need to
lock.

For the actual functionality you are using it for locking on a static
object and locking on the FileLogger type should be identical. Could you
post the link to the article you're reading that says you shouldn't lock on
typeof(classname)? From everything I understand that is a perfectly valid
thing to do when that's the functionality you want. It's certainly in a lot
of Microsoft documentation.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

Hi Andrew

After I read some website, now the code is changed like as follow

inside FileLogger,

private static readonly object = new object();

public void Log()
{
lock (object)
{
WriteLogToTextFile();
}
}

I am not sure why using static, but they always said lock a static object
should be better than lock a type.

Thanks

Nothing wrong with using Lock. Especially when you are using it for as
minimal of sections of code as possible. However, there are two things
I'd recommend changing. First, use lock(typeof(FileLogger)) calling
typeof on an actual object instead of a type name should throw a
compiler error. Second, I would move the lock within the Log method
itself. If you need the operation to always be threadsafe then the
operation itself should be responsible to ensure that it is. As you have
it written now, you have no guarantee of thread safety. If you forget to
lock even one call anywhere to the log method you could have issues.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

I am writing a Logging util for my ASP.NET application.
I am facing mulit process problem.

I developed a class LogFactory, and have a method called Get_Logger to
create a FileLogger, which will write text into a text file.

// sample code

FileLogger logger = LogFactory.Get_Logger();
logger.Log("Message here");
logger = null;

I read a lot of example that when we face the mulit process problem, we
can use the keyword "lock" to solve the problem
// example
File logger logger = LogFactory.Get_Logger();
lock (typeof (logger))
{
log.Log("Message here");
}
logger = null;

although a lot of article said that DONT use lock(typeof(logger))
because it is a slow process and it will lock all objects, which in the
same application, and used in other process. However, I think in my
case, I can use typeof(logger) because I am try to write the message in
a single text file, no matter which process a instancing the logger
object, I only need to lock the text file, write text, release it and
then other process repeat the same step, right?

So my code is correct?? or any other better solution? Thanks

 

[WingSiu]

Hi Andrew,

FYR
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraskdr/html/askgui06032003.asp

Locking on a static object will work fine in your situation. The way lock
works is by using whatever is in the lock() parameter as a key for that
code block. .Net differentiates between actual instances of objects. Thus
if you need a class wide lock you have three options. Lock on a static
object, lock on the actual class itself typeof(ClassName) or lock on an
instance of an object that you pass around to all the classes that need to
lock.

For the actual functionality you are using it for locking on a static
object and locking on the FileLogger type should be identical. Could you
post the link to the article you're reading that says you shouldn't lock
on typeof(classname)? From everything I understand that is a perfectly
valid thing to do when that's the functionality you want. It's certainly
in a lot of Microsoft documentation.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

Hi Andrew

After I read some website, now the code is changed like as follow

inside FileLogger,

private static readonly object = new object();

public void Log()
{
lock (object)
{
WriteLogToTextFile();
}
}

I am not sure why using static, but they always said lock a static object
should be better than lock a type.

Thanks

Nothing wrong with using Lock. Especially when you are using it for as
minimal of sections of code as possible. However, there are two things
I'd recommend changing. First, use lock(typeof(FileLogger)) calling
typeof on an actual object instead of a type name should throw a
compiler error. Second, I would move the lock within the Log method
itself. If you need the operation to always be threadsafe then the
operation itself should be responsible to ensure that it is. As you have
it written now, you have no guarantee of thread safety. If you forget to
lock even one call anywhere to the log method you could have issues.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com


I am writing a Logging util for my ASP.NET application.
I am facing mulit process problem.

I developed a class LogFactory, and have a method called Get_Logger to
create a FileLogger, which will write text into a text file.

// sample code

FileLogger logger = LogFactory.Get_Logger();
logger.Log("Message here");
logger = null;

I read a lot of example that when we face the mulit process problem, we
can use the keyword "lock" to solve the problem
// example
File logger logger = LogFactory.Get_Logger();
lock (typeof (logger))
{
log.Log("Message here");
}
logger = null;

although a lot of article said that DONT use lock(typeof(logger))
because it is a slow process and it will lock all objects, which in the
same application, and used in other process. However, I think in my
case, I can use typeof(logger) because I am try to write the message in
a single text file, no matter which process a instancing the logger
object, I only need to lock the text file, write text, release it and
then other process repeat the same step, right?

So my code is correct?? or any other better solution? Thanks

 

[WingSiu]

Hi Andrew,

FYR
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraskdr/html/askgui06032003.asp

Locking on a static object will work fine in your situation. The way lock
works is by using whatever is in the lock() parameter as a key for that
code block. .Net differentiates between actual instances of objects. Thus
if you need a class wide lock you have three options. Lock on a static
object, lock on the actual class itself typeof(ClassName) or lock on an
instance of an object that you pass around to all the classes that need to
lock.

For the actual functionality you are using it for locking on a static
object and locking on the FileLogger type should be identical. Could you
post the link to the article you're reading that says you shouldn't lock
on typeof(classname)? From everything I understand that is a perfectly
valid thing to do when that's the functionality you want. It's certainly
in a lot of Microsoft documentation.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

Hi Andrew

After I read some website, now the code is changed like as follow

inside FileLogger,

private static readonly object = new object();

public void Log()
{
lock (object)
{
WriteLogToTextFile();
}
}

I am not sure why using static, but they always said lock a static object
should be better than lock a type.

Thanks

Nothing wrong with using Lock. Especially when you are using it for as
minimal of sections of code as possible. However, there are two things
I'd recommend changing. First, use lock(typeof(FileLogger)) calling
typeof on an actual object instead of a type name should throw a
compiler error. Second, I would move the lock within the Log method
itself. If you need the operation to always be threadsafe then the
operation itself should be responsible to ensure that it is. As you have
it written now, you have no guarantee of thread safety. If you forget to
lock even one call anywhere to the log method you could have issues.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com


I am writing a Logging util for my ASP.NET application.
I am facing mulit process problem.

I developed a class LogFactory, and have a method called Get_Logger to
create a FileLogger, which will write text into a text file.

// sample code

FileLogger logger = LogFactory.Get_Logger();
logger.Log("Message here");
logger = null;

I read a lot of example that when we face the mulit process problem, we
can use the keyword "lock" to solve the problem
// example
File logger logger = LogFactory.Get_Logger();
lock (typeof (logger))
{
log.Log("Message here");
}
logger = null;

although a lot of article said that DONT use lock(typeof(logger))
because it is a slow process and it will lock all objects, which in the
same application, and used in other process. However, I think in my
case, I can use typeof(logger) because I am try to write the message in
a single text file, no matter which process a instancing the logger
object, I only need to lock the text file, write text, release it and
then other process repeat the same step, right?

So my code is correct?? or any other better solution? Thanks

 

[WingSiu]

Hi Andrew,

FYR
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraskdr/html/askgui06032003.asp

Locking on a static object will work fine in your situation. The way lock
works is by using whatever is in the lock() parameter as a key for that
code block. .Net differentiates between actual instances of objects. Thus
if you need a class wide lock you have three options. Lock on a static
object, lock on the actual class itself typeof(ClassName) or lock on an
instance of an object that you pass around to all the classes that need to
lock.

For the actual functionality you are using it for locking on a static
object and locking on the FileLogger type should be identical. Could you
post the link to the article you're reading that says you shouldn't lock
on typeof(classname)? From everything I understand that is a perfectly
valid thing to do when that's the functionality you want. It's certainly
in a lot of Microsoft documentation.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

Hi Andrew

After I read some website, now the code is changed like as follow

inside FileLogger,

private static readonly object = new object();

public void Log()
{
lock (object)
{
WriteLogToTextFile();
}
}

I am not sure why using static, but they always said lock a static object
should be better than lock a type.

Thanks

Nothing wrong with using Lock. Especially when you are using it for as
minimal of sections of code as possible. However, there are two things
I'd recommend changing. First, use lock(typeof(FileLogger)) calling
typeof on an actual object instead of a type name should throw a
compiler error. Second, I would move the lock within the Log method
itself. If you need the operation to always be threadsafe then the
operation itself should be responsible to ensure that it is. As you have
it written now, you have no guarantee of thread safety. If you forget to
lock even one call anywhere to the log method you could have issues.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com


I am writing a Logging util for my ASP.NET application.
I am facing mulit process problem.

I developed a class LogFactory, and have a method called Get_Logger to
create a FileLogger, which will write text into a text file.

// sample code

FileLogger logger = LogFactory.Get_Logger();
logger.Log("Message here");
logger = null;

I read a lot of example that when we face the mulit process problem, we
can use the keyword "lock" to solve the problem
// example
File logger logger = LogFactory.Get_Logger();
lock (typeof (logger))
{
log.Log("Message here");
}
logger = null;

although a lot of article said that DONT use lock(typeof(logger))
because it is a slow process and it will lock all objects, which in the
same application, and used in other process. However, I think in my
case, I can use typeof(logger) because I am try to write the message in
a single text file, no matter which process a instancing the logger
object, I only need to lock the text file, write text, release it and
then other process repeat the same step, right?

So my code is correct?? or any other better solution? Thanks

 

[Andrew Faust]

Thanks, that was definitely worth reading. If you got to Rico Mariani's
blog http://blogs.msdn.com/ricom/archive/2003/12/06/41779.aspx he also
recommends using a constant string value such as "MyLock" for the lock
object as well. It looks I've got some code to go modify.

One interesting thing to note is that in the article you linked Rico
mentions that the documentation would be updated "soon" to remove the
references to locking on the class type. That was 4 years ago and it still
hasn't happened. I figured it was proper purely because Microsoft is still
using it as an example:

http://msdn2.microsoft.com/en-us/library/aa664735(VS.71).aspx

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

Hi Andrew,

FYR
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraskdr/html/askgui06032003.asp

Locking on a static object will work fine in your situation. The way
lock works is by using whatever is in the lock() parameter as a key for
that code block. .Net differentiates between actual instances of
objects. Thus if you need a class wide lock you have three options. Lock
on a static object, lock on the actual class itself typeof(ClassName) or
lock on an instance of an object that you pass around to all the classes
that need to lock.

For the actual functionality you are using it for locking on a static
object and locking on the FileLogger type should be identical. Could you
post the link to the article you're reading that says you shouldn't lock
on typeof(classname)? From everything I understand that is a perfectly
valid thing to do when that's the functionality you want. It's certainly
in a lot of Microsoft documentation.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

Hi Andrew

After I read some website, now the code is changed like as follow

inside FileLogger,

private static readonly object = new object();

public void Log()
{
lock (object)
{
WriteLogToTextFile();
}
}

I am not sure why using static, but they always said lock a static
object should be better than lock a type.

Thanks

"Andrew Faust" <[email protected]>
???????[email protected]...
Nothing wrong with using Lock. Especially when you are using it for as
minimal of sections of code as possible. However, there are two things
I'd recommend changing. First, use lock(typeof(FileLogger)) calling
typeof on an actual object instead of a type name should throw a
compiler error. Second, I would move the lock within the Log method
itself. If you need the operation to always be threadsafe then the
operation itself should be responsible to ensure that it is. As you
have it written now, you have no guarantee of thread safety. If you
forget to lock even one call anywhere to the log method you could have
issues.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com


I am writing a Logging util for my ASP.NET application.
I am facing mulit process problem.

I developed a class LogFactory, and have a method called Get_Logger
to create a FileLogger, which will write text into a text file.

// sample code

FileLogger logger = LogFactory.Get_Logger();
logger.Log("Message here");
logger = null;

I read a lot of example that when we face the mulit process problem,
we can use the keyword "lock" to solve the problem
// example
File logger logger = LogFactory.Get_Logger();
lock (typeof (logger))
{
log.Log("Message here");
}
logger = null;

although a lot of article said that DONT use lock(typeof(logger))
because it is a slow process and it will lock all objects, which in
the same application, and used in other process. However, I think in
my case, I can use typeof(logger) because I am try to write the
message in a single text file, no matter which process a instancing
the logger object, I only need to lock the text file, write text,
release it and then other process repeat the same step, right?

So my code is correct?? or any other better solution? Thanks

 

[WingSiu]

Yes, because all string "MyLock" will reference to the same address
(pointer), so it is very similar to using static object.

And when you see following url, they mentioned the problem of lock typeof
http://msdn2.microsoft.com/en-us/library/c5kehkcz(VS.80).aspx

It is very funny....

Thanks, that was definitely worth reading. If you got to Rico Mariani's
blog http://blogs.msdn.com/ricom/archive/2003/12/06/41779.aspx he also
recommends using a constant string value such as "MyLock" for the lock
object as well. It looks I've got some code to go modify.

One interesting thing to note is that in the article you linked Rico
mentions that the documentation would be updated "soon" to remove the
references to locking on the class type. That was 4 years ago and it still
hasn't happened. I figured it was proper purely because Microsoft is still
using it as an example:

http://msdn2.microsoft.com/en-us/library/aa664735(VS.71).aspx

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com

Hi Andrew,

FYR
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraskdr/html/askgui06032003.asp

Locking on a static object will work fine in your situation. The way
lock works is by using whatever is in the lock() parameter as a key for
that code block. .Net differentiates between actual instances of
objects. Thus if you need a class wide lock you have three options. Lock
on a static object, lock on the actual class itself typeof(ClassName) or
lock on an instance of an object that you pass around to all the classes
that need to lock.

For the actual functionality you are using it for locking on a static
object and locking on the FileLogger type should be identical. Could you
post the link to the article you're reading that says you shouldn't lock
on typeof(classname)? From everything I understand that is a perfectly
valid thing to do when that's the functionality you want. It's certainly
in a lot of Microsoft documentation.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com


Hi Andrew

After I read some website, now the code is changed like as follow

inside FileLogger,

private static readonly object = new object();

public void Log()
{
lock (object)
{
WriteLogToTextFile();
}
}

I am not sure why using static, but they always said lock a static
object should be better than lock a type.

Thanks

"Andrew Faust" <[email protected]>
???????[email protected]...
Nothing wrong with using Lock. Especially when you are using it for as
minimal of sections of code as possible. However, there are two things
I'd recommend changing. First, use lock(typeof(FileLogger)) calling
typeof on an actual object instead of a type name should throw a
compiler error. Second, I would move the lock within the Log method
itself. If you need the operation to always be threadsafe then the
operation itself should be responsible to ensure that it is. As you
have it written now, you have no guarantee of thread safety. If you
forget to lock even one call anywhere to the log method you could have
issues.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com


I am writing a Logging util for my ASP.NET application.
I am facing mulit process problem.

I developed a class LogFactory, and have a method called Get_Logger
to create a FileLogger, which will write text into a text file.

// sample code

FileLogger logger = LogFactory.Get_Logger();
logger.Log("Message here");
logger = null;

I read a lot of example that when we face the mulit process problem,
we can use the keyword "lock" to solve the problem
// example
File logger logger = LogFactory.Get_Logger();
lock (typeof (logger))
{
log.Log("Message here");
}
logger = null;

although a lot of article said that DONT use lock(typeof(logger))
because it is a slow process and it will lock all objects, which in
the same application, and used in other process. However, I think in
my case, I can use typeof(logger) because I am try to write the
message in a single text file, no matter which process a instancing
the logger object, I only need to lock the text file, write text,
release it and then other process repeat the same step, right?

So my code is correct?? or any other better solution? Thanks