Rob-
well, unlike the other data synchronization mechanisms the critical section
can only be used by threads within the same process. the others mechanisms
are kernel objects and can span across all processes and synchronize data
access system wide, so the best one to use will depend on the requirements
of your code. Also, you mentioned multiple objects of the wrapper being
created. is it multiple objects of the wrapper or multiple instances of the
same object? also, is your wrapper an INPROC_SERVER, LOCAL_SERVER, or
REMOTE_SERVER because of the differences in implementation of each that
would help me determine the best advise to give

>From: Robert Sedor <rsedorHOME.COM>
>Reply-To: Distributed COM-Based Code <DCOMDISCUSS.MICROSOFT.COM>
>To: DCOMDISCUSS.MICROSOFT.COM
>Subject: Re: SPM and DLL memory, Apartments and Threading
>Date: Sat, 21 Jul 2001 18:08:59 -0400
>
>Will wrapping the DLL call in a critical section be consistent when
>multiple
>objects of the wrapper will be created?
>
>In COM+, will it be the equivelent of multiple processes or multiple
>threads
>creating objects? In which case, is it better with a
>critical section or a semaphore or mutex?
>
>Anyway I look at it, it looks like a disaster, but the quasi singleton in
>the spm approach is definitely the worst.
>
>Thank you for opening up some new possibility.
>
>Robert
>
>----- Original Message -----
>From: "Eric Strain" <eric_strainHOTMAIL.COM>
>To: <DCOMDISCUSS.MICROSOFT.COM>
>Sent: Saturday, July 21, 2001 4:50 PM
>Subject: Re: SPM and DLL memory, Apartments and Threading
>
>
> > If the said department is correct, and the win32.dll they created is
>indeed
> > "not thread safe" then that brings to mind the possibility of blocking
> > thread calls, in which one thread accesses the dll, followed by another
> > thread also accessing the dll, thread 'B' is blocked from further
>processing
> > until thread 'A' is finished and releases the dll. Which is in the best
>case
> > scenerio annoying and in efficient, and in the worst case scenerio could
> > lead to a permenant blocking thread call situation. The single-thread
> > apartment STA is the traditional COM environment where all
>multithreading
> > synchronization is accomplished via the windows message pump. COM sends
> > windows messages to the COM object and forces the synchronization in
>much
> > the same way you would force only a single thread of execution using a
> > critical section. As for whether or not this is unsafe, it is definately
>a
> > disaster waiting to happen. As for being able to use/wrap the dll
>safely,I
> > would suggest writing your code and placeing calls that access the dll
> > within a critical section, semaphore or other such construct to aid in
>the
> > necessary synchronization and watch your calls to Release() so that the
> > IUnknown* is not deleted until your actually finished with it, loosing
>track
> > of the outstanding AddRef() calls can lead to access violations when you
> > least expect it. I hope this helps and Good Luck..
> >
> >
> > >From: "Robert P. Sedor" <rsedorHOME.COM>
> > >Reply-To: Distributed COM-Based Code <DCOMDISCUSS.MICROSOFT.COM>
> > >To: DCOMDISCUSS.MICROSOFT.COM
> > >Subject: SPM and DLL memory, Apartments and Threading
> > >Date: Fri, 20 Jul 2001 19:36:33 -0400
> > >
> > >We are currently using a COM component which is created and then stored
>in
> > >the SPM in MTS. This component uses a regular Win32 dll that in turn
>uses
> > >statics and globals (legacy windows code). Another department at work
>has
> > >created the Win32 dll and we cannot access its code, and we were
>initially
> > >instructed by said department to create a COM component wrapper for it
>and
> > >then use the component in the SPM sort of like a singleton.
> > >
> > >Initially, this might appear to be a state issue, but it is not. The
>other
> > >department has insisted that since the Win32 dll is not thread safe and
> > >uses statics and globals, that only one instance can be created at a
>time.
> > >Hence, the wrapper being created once and stored in the SPM.
> > >
> > >I have pulled out both Richter's "Progamming Windows Applications" and
>Tim
> > >Ewalds "Transactional COM+" books and cannot figure out how this could
>be.
> > >
> > >If anyone has made it this far, my questions are thus:
> > >
> > >1. What is the problem with using a non thread safe Win32 dll from
>single
> > >apartment threaded objects in COM+?
> > >2. If a non thread safe Win32 dll is loaded by an object in COM+, and a
> > >DLL's file image is mapped into the calling process's address space how
> > >does this affect COM+ objects? In other words, a COM object belongs to
>an
> > >apartment, and a thread can enter an apartment, so who owns the DLL's
>image
> > >when a DLL's file image is loaded by a process?
> > >3. How is the DLL's image shared by different COM objects within COM+?
> > >
> > >Basically, I want to know how unsafe this is, and if it is unsafe, how
>can
> > >I use/wrap the unsafe dll so that I can use it safely from my COM+
>objects.
> > >
> > >Thanks to anyone who read this whole story!
> > >
> > >Robert Sedor
> > >Pitney Bowes
> > >Shelton, CT
> > >robert.sedorpb.com
> > >rsedorhome.com
> > >
> > >----------------------------------------------------------------
> > >Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
> > >contains important info. Save time, search the archives at
> > >http://discuss.microsoft.com/archives/index.html .
> > >To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
> >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
>http://explorer.msn.com/intl.asp
> >
> > ----------------------------------------------------------------
> > Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
> > contains important info. Save time, search the archives at
> > http://discuss.microsoft.com/archives/index.html .
> > To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>
>----------------------------------------------------------------
>Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
>contains important info. Save time, search the archives at
>http://discuss.microsoft.com/archives/index.html .
>To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

----------------------------------------------------------------
Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]