|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Is synclock needed in DLL?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 You can use lock in the DLL and then claim that the DLLs FileWrite method is
thread safe :-) HTH rawCoder Show quoteHide quote "Brett" <no@spam.net> wrote in message news:uUB5Wy1OFHA.4028@tk2msftngp13.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 ReaderWriterLock) be used inside the application, > surrounding the FileWrite() call or inside the DLL's FileWrite() method? > > Thanks, > Bretrt > > 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 Show quoteHide quote "rawCoder" <rawCo***@hotmail.com> wrote in message news:utxX2K2OFHA.624@TK2MSFTNGP10.phx.gbl... > You can use lock in the DLL and then claim that the DLLs FileWrite method > is > thread safe :-) > > HTH > rawCoder > > "Brett" <no@spam.net> wrote in message > news:uUB5Wy1OFHA.4028@tk2msftngp13.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 ReaderWriterLock) be used inside the application, >> surrounding the FileWrite() call or inside the DLL's FileWrite() method? >> >> Thanks, >> Bretrt >> >> > > 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/default.asp?url=/library/en-us/cpref/html/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. ---- rawCoder Show quoteHide quote "Brett" <no@spam.net> wrote in message news:u%23BC$j2OFHA.1040@TK2MSFTNGP12.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" <rawCo***@hotmail.com> wrote in message > news:utxX2K2OFHA.624@TK2MSFTNGP10.phx.gbl... > > You can use lock in the DLL and then claim that the DLLs FileWrite method > > is > > thread safe :-) > > > > HTH > > rawCoder > > > > "Brett" <no@spam.net> wrote in message > > news:uUB5Wy1OFHA.4028@tk2msftngp13.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 ReaderWriterLock) be used inside the application, > >> surrounding the FileWrite() call or inside the DLL's FileWrite() method? > >> > >> Thanks, > >> Bretrt > >> > >> > > > > > > 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. 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 Show quoteHide quote On Thu, 7 Apr 2005 06:28:45 -0400, "Brett" <no@spam.net> wrote: B-Line is now hiring one Washington D.C. area VB.NET >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 > developer for WinForms + WebServices position. Seaking mid to senior level developer. For information or to apply e-mail resume to sam_blinex_com. 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 Show quoteHide quote "Samuel R. Neff" <blinex@newsgroup.nospam> wrote in message news:db2b519n0f47lvd66lgodsurbqnnjo5uub@4ax.com... > > 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 > > > On Thu, 7 Apr 2005 06:28:45 -0400, "Brett" <no@spam.net> wrote: > >>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. 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" <no@spam.com> wrote: B-Line is now hiring one Washington D.C. area VB.NET >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 > developer for WinForms + WebServices position. Seaking mid to senior level developer. For information or to apply e-mail resume to sam_blinex_com. 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 Show quoteHide quote "Samuel R. Neff" <blinex@newsgroup.nospam> wrote in message news:5p5b519f0j7qqql342k6dnbi135sn7h5vm@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 > > > On Thu, 7 Apr 2005 16:08:44 -0400, "Brett" <no@spam.com> 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. Yup, that's the pattern.
Sam Show quoteHide quote On Thu, 7 Apr 2005 17:46:38 -0400, "Brett" <no@spam.com> wrote: B-Line is now hiring one Washington D.C. area VB.NET >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" <blinex@newsgroup.nospam> wrote in message >news:5p5b519f0j7qqql342k6dnbi135sn7h5vm@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 developer for WinForms + WebServices position. Seaking mid to senior level developer. For information or to apply e-mail resume to sam_blinex_com. 
Other interesting topics
|
|||||||||||||||||||||||
