Access to the variables and resources protected by locks takes place sequentially among the different threads. We have locks around the parser, PROJ initialization, GDAL initialization, connection pooling global data, error object ... For example when parsing the .map file multiple requests will waiting for each other within the same host process. I think it brings in a significant performance degradation and kills the scalability :( Spawning multiple processes for the requests seems to be better this time if the extra overhead of creating a process is acceptable. This behaviour may change in the future.
Tamas 2006/6/26, Jeff Dege <[EMAIL PROTECTED]>:
> -----Original Message----- > From: Tamas Szekeres [mailto:[EMAIL PROTECTED] > Sent: Friday, June 23, 2006 5:28 PM > To: Jeff Dege > Cc: [email protected] > Subject: Re: [UMN_MAPSERVER-USERS] Thread-safety in > mapscript_csharp.dll? > > > Are you suggesting that we should protect access to the mapserver > > objects within the C# code, using the C# lock statement? Or are the > > locks within the mapscript_csharp.dll sufficient? > > > > Nope. This kind of synchronization can only take place at the > unmanaged side when using the IIS ASP.NET application models. The > mapserver code should make the necessary work for you. What kind of impact do these locks have on performance, as the number of simultaneous users increases?
