On 01/26/2011 11:12 AM, David Rees wrote: > On Wed, Jan 19, 2011 at 11:53 PM, Dennis Sosnoski <[email protected]> wrote: > >> The stubs are reusable, but not reentrant - so if you're running >> multiple threads you'll want to either create a new one each time >> (higher overhead), cache them per thread, or synchronize around each use >> (only if there's not much use, of course - in which case you're probably >> better off creating a new one each time anyway). >> > Wait - so are you saying (stubs are not reentrant) that if you > maintain a common pool of stubs that gets used across multiple threads > - that is not supported? > > Because I've been doing that successfully for a LONG time now. >
Just noticed this reply on an earlier thread. If you're using a pool of stubs that's different from trying to share a single stub across multiple threads. However, based on what I've seen in the code you still need to have a memory barrier (i.e., a synchronization) somewhere in the process of getting the stub for a thread. Normally your pool would use synchronization as part of the allocation and deallocation, so that should not be a problem. That said, a lot of code works fine without synchronization as long as it's executing on processors with a uniform memory architecture (because each thread "sees" the other threads' changes automatically). But when you deploy code with incomplete synchronization to servers with multiple processors and multiple levels of caching it can cause bizarre crashes. - Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
