Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Multithreading ADSI

4 views
Skip to first unread message

Shai

unread,
Dec 24, 2003, 8:49:24 AM12/24/03
to
I have a COM object that access IIS and Active Directory
using ADSI. The object is written in c++ and is configured
to run in an apartment threading model.
I want to improve the object performance by making it
multi-threaded. I have found a short notesaying that ADSI
is not multi-threaded and the syncronization should be
used.
Is there somewhere some more details on how to syncronize
access to ADSI? What function calls should be syncronized?
are the ADSI objects reentrant? etc.

Thanks,
Shai

Valery Pryamikov

unread,
Jan 5, 2004, 4:06:55 AM1/5/04
to
Hi,
Threading model of the ADSI objects is dependent on the provider, but it is
fair to consider some of them not being thread safe, esp any data container
objects because adding extra locks would only degrade performance of
non-shared objects scenarios (which is used in 99% of cases), while as these
locks still would not provide contaner consistency because last requires
full transactions support (just consider two threads changing properties
concurently - lock can prevent each single property corruption, but property
value itself will be dependent on which thread was the last to change the
property and consistency of the container usualy defined by the combination
of several properties...)
For increasing performance of your COM object I'd rather sugest you to do
following:
1. do not cache your COM objects in ASP session and do not share them across
the threads by any other means.
2. share only your COM object's initialization parameters (like strings and
numbers).
3. create new instance and initialize your COM object every time your
program need to use it and destroy it when you are done.
CoCreateInstance is quite optimized for CLSIDs that were already created in
the current process - you don't get registry lookup and dll load hits. And
the change from shared objects to single object consumer scenarios requires
less redesign cost (compared to change of threading model) always gives
better scalalability and most of the time it also gives performance win.

-Valery.

"Shai" <mys...@hotmail.co.il> wrote in message
news:07c701c3ca24$bd8f62b0$a301...@phx.gbl...

0 new messages