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 ReaderWriterLock) 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]

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]

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/d...frlrfsystemcollectionsarraylistclasstopic.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.

 

[Dick Grier]

Hi,
Should SyncLock (or ReaderWriterLock) 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]

If the DLL is used from other applications that are not multi-threaded
(or are not multithreaded in the areas they use the DLL) then the DLL
either should not have the locks or should provide both synchronized
and non-synchronized methods.

The issue is locking has a performance hit (very slight, but
something) so you don't want to do it unnecessarily. However, for
something like a file write operation, the performance hit of a lock
is nothing compared to the overall operation, so in this particular
case it's much less of a concern. For other classes such as
collections, the lookup of a collection is fast and the performance
hit there has an impact on the overal performance of the method. For
these situations many collections provide a Synchronized version.

HTH,

Sam

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 ReaderWriterLock) be used inside the application,
surrounding the FileWrite() call or inside the DLL's FileWrite() method?

Thanks,
Bretrt

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 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

 

[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

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]

Yup, that's the pattern.

Sam

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

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.