Is synclock needed in DLL?

[Brett]

Say I have a DLL with a method that does a file write. I call this DLL from
an application and pass the file path and name to the FileWrite() method
inside the DLL. The application is multi threaded so that two or more
threads may be trying to write to the file at once. If one thread is
writing then another comes along and trys to write, it will get a file in
use error.

Should SyncLock (or ReaderWriterLoc k) be used inside the application,
surrounding the FileWrite() call or inside the DLL's FileWrite() method?

Thanks,
Bretrt

[rawCoder]

You can use lock in the DLL and then claim that the DLLs FileWrite method is
thread safe :-)

HTH
rawCoder

"Brett" <[e-mail]> wrote in message
news:uU******** ******@tk2msftn gp13.phx.gbl...

Say I have a DLL with a method that does a file write. I call this DLL from an application and pass the file path and name to the FileWrite() method
inside the DLL. The application is multi threaded so that two or more
threads may be trying to write to the file at once. If one thread is
writing then another comes along and trys to write, it will get a file in
use error.

Should SyncLock (or ReaderWriterLoc k) be used inside the application,
surrounding the FileWrite() call or inside the DLL's FileWrite() method?

Thanks,
Bretrt

[Brett]

So the DLL's lock will affect threading in the calling application? If so,
that's good because now I don't have to retrofit the app with Locks to every
one of the DLL FileWrite() methods.

What do you mean by "claim"? Are there scenarios where it won't be thread
safe?

Thanks,
Brett
"rawCoder" <ra******@hotma il.com> wrote in message
news:ut******** *****@TK2MSFTNG P10.phx.gbl...

You can use lock in the DLL and then claim that the DLLs FileWrite method
is
thread safe :-)

HTH
rawCoder

"Brett" <[e-mail]> wrote in message
news:uU******** ******@tk2msftn gp13.phx.gbl...

Say I have a DLL with a method that does a file write. I call this DLL

from

an application and pass the file path and name to the FileWrite() method
inside the DLL. The application is multi threaded so that two or more
threads may be trying to write to the file at once. If one thread is
writing then another comes along and trys to write, it will get a file in
use error.

Should SyncLock (or ReaderWriterLoc k) be used inside the application,
surrounding the FileWrite() call or inside the DLL's FileWrite() method?

Thanks,
Bretrt

[rawCoder]

I meant that currently ur method is not thread safe for the caller.
Ever seen this 'CLAIM' on MSDN :-)

----
for e.g. at
http://msdn.microsoft.com/library/de...classtopic.asp
Thread Safety
Public static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Instance members are not guaranteed to be
thread-safe.
----

rawCoder

"Brett" <[e-mail]> wrote in message
news:u%******** ********@TK2MSF TNGP12.phx.gbl. ..

So the DLL's lock will affect threading in the calling application? If so, that's good because now I don't have to retrofit the app with Locks to every one of the DLL FileWrite() methods.

What do you mean by "claim"? Are there scenarios where it won't be thread
safe?

Thanks,
Brett
"rawCoder" <ra******@hotma il.com> wrote in message
news:ut******** *****@TK2MSFTNG P10.phx.gbl...

You can use lock in the DLL and then claim that the DLLs FileWrite method is
thread safe :-)

HTH
rawCoder

"Brett" <[e-mail]> wrote in message
news:uU******** ******@tk2msftn gp13.phx.gbl...

Say I have a DLL with a method that does a file write. I call this DLL

from

an application and pass the file path and name to the FileWrite() method inside the DLL. The application is multi threaded so that two or more
threads may be trying to write to the file at once. If one thread is
writing then another comes along and trys to write, it will get a file in use error.

Should SyncLock (or ReaderWriterLoc k) be used inside the application,
surrounding the FileWrite() call or inside the DLL's FileWrite() method?
Thanks,
Bretrt

[Dick Grier]

Hi,

Should SyncLock (or ReaderWriterLoc k) be used inside the application,
surrounding the FileWrite() call or inside the DLL's FileWrite() method?
<<

Yes (or Monitor) -- as long as you use the same Object to SyncLock for all
threads. And, you have to make sure that you don't dead-lock. That is,
you have to make sure that no tread can call a lock and not release it -- or
that one thread's execution does not depend on that of another thread, where
both are sharing this common write method.

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.

[Samuel R. Neff]

No, it's one set of code, just the synchronized version wraps the
non-synchronized one.

For example, the .NET framework provides two classes ArrayList and
SyncArrayList. The difference is that ArrayList is non thread safe
byt SyncArrayList is.

ArrayList is the class that has all of the functionality for managing
a dynamic array.

SyncArrayList simply wraps an ArrayList and has all the same
properties and methods and wraps all of the calls in a synclock.

So there is more code to maintain, but it's not duplicate code.

As far as performance, it's all relative and whether you need to worry
about it depends on the operation and expected number of calls.

HTH,

Sam
On Thu, 7 Apr 2005 16:08:44 -0400, "Brett" <[e-mail]> wrote:

I think the performance hit would be very smalll in most every case. The
first method you described requires keeping track of two sets of
code...correct ?

Thanks,
Brett

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

[Brett]

I think I see now. Calling SyncArrayList is an indirect call to ArrayList.
So in my DLL, I have some type of synclock wrapper sub that calls the non
thread safe subs and puts them between the syncLocks, depending on what the
user wants...right?

Thanks,
Brett
"Samuel R. Neff" <bl****@newsgro up.nospam> wrote in message
news:5p******** *************** *********@4ax.c om...

No, it's one set of code, just the synchronized version wraps the
non-synchronized one.

For example, the .NET framework provides two classes ArrayList and
SyncArrayList. The difference is that ArrayList is non thread safe
byt SyncArrayList is.

ArrayList is the class that has all of the functionality for managing
a dynamic array.

SyncArrayList simply wraps an ArrayList and has all the same
properties and methods and wraps all of the calls in a synclock.

So there is more code to maintain, but it's not duplicate code.

As far as performance, it's all relative and whether you need to worry
about it depends on the operation and expected number of calls.

HTH,

Sam
On Thu, 7 Apr 2005 16:08:44 -0400, "Brett" <[e-mail]> wrote:

I think the performance hit would be very smalll in most every case. The
first method you described requires keeping track of two sets of
code...correc t?

Thanks,
Brett

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

[Samuel R. Neff]

Yup, that's the pattern.

Sam
On Thu, 7 Apr 2005 17:46:38 -0400, "Brett" <[e-mail]> wrote:

I think I see now. Calling SyncArrayList is an indirect call to ArrayList.
So in my DLL, I have some type of synclock wrapper sub that calls the non
thread safe subs and puts them between the syncLocks, depending on what the
user wants...right?

Thanks,
Brett
"Samuel R. Neff" <bl****@newsgro up.nospam> wrote in message
news:5p******* *************** **********@4ax. com...

No, it's one set of code, just the synchronized version wraps the
non-synchronized one.

For example, the .NET framework provides two classes ArrayList and
SyncArrayList. The difference is that ArrayList is non thread safe
byt SyncArrayList is.

ArrayList is the class that has all of the functionality for managing
a dynamic array.

SyncArrayList simply wraps an ArrayList and has all the same
properties and methods and wraps all of the calls in a synclock.

So there is more code to maintain, but it's not duplicate code.

As far as performance, it's all relative and whether you need to worry
about it depends on the operation and expected number of calls.

HTH,

Sam

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.