[Mono-list] Re: Consuming unmanged code, global/static variables,
chrisandharris at gmail.com
Thu Feb 23 09:56:59 EST 2006
Thank you for your suggestions.
What about C# wrapper classes that were singletons and had locks that would
take care of race conditions, initializing the library in global?
On 2/23/06, Robert Jordan <robertj at gmx.net> wrote:
> > Looking for some guidelines on consuming some of our library (in C) into
> > .NET for use with ASP.NET pages
> > I'm concerned about our global and static variables that are needed in
> > of our libraries. In a single threaded C# application this would be no
> > problem. Initialize the libraries at startup, destroy on close.
> > But for ASP.NET pages, how would I handle initialization, since multiple
> > pages are being served at the same time making use of these libraries?
> Are your native libraries thread safe? If yes, you usually don't
> have to care about the initialization. If they are not: welcome to a
> world of pain.
> > Would I initiailze for each page request as needed in the C# code behind
> > page? Or is this going to have problems when multiple requests are
> It won't work. Go ahead and fix the native library. Everything
> else is a waste of time.
> > Also what about a function that contains a static variable?
> You have to rewrite them to use a TLS slot instead of the
> static variable. If the content of the static variable is
> thread invariant, a lock for its initialization might be sufficient.
> The same has to be done with static variables outside
> of functions as well.
> > Basically these are the questions I have, but I just can't find any
> > resources to explain how ASP.NET applications are threaded, and how it
> > effect consumption of unmanaged libraries. If anyone can even point me
> > the right direction I'd be very grateful.
> The threading model of ASP.NET is quite straightforward for
> the developer: one cannot predict by which thread the request
> will be handled. This implies that the ASP.NET consumer has
> to deal with concurrency all the time.
> Mono-list maillist - Mono-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-list