Shared global data in multi-plugin file

Question

Ok, I see that in the SelectoramaShape example that it is possible to put multiple plug-ins in a single file...cool. My question: is global data visible/shareable between the plug-ins?
My situation is this: I have a visible filter plug-in ("Trigger"), a hidden persistent automation plug-in ("Master"), and a hidden filter plug-in ("Slave").
The idea is for Trigger to do the 'public' stuff (read/write scripting parameters, put up and manage the UI etc). Master listens for it to finish, does some things filters can't do (e.g. create an adjustment layer), and then commands Slave to do the heavy lifting (e.g. read from a specified pixel layer and write out to the mask of the newly-created adjustment layer). So far I have the three plug-ins doing pretty much nothing, all in the same .8bf file. What seems to work is that Master indeed sees Trigger run and successfully executes Slave. And all three seem to be able to read/write shared global data structures without causing BSODs or global warming.
My concern is that a plug-in is a DLL, the key word in that acronym being "dynamic": I'm worried that things will move around or whatever, and/or that I'm doing something blatantly illegal by not allocating/deallocating/registering/whatever and using multiple levels of abstraction to read/write a fistful of integer values. Is the fact that it seems to be working an artifact of having 16GB of RAM, so nothing ever moves? Does the "persistent" setting for Master keep it locked down? Or am I just totally overthinking this whole thing?
(This can't possibly be an original question, but the search function on this forum doesn't play well with me. Feel free to just post a link to a FAQ or something.)

Answer 1

The C library is shareable. But you don't want it to be shared. That's your question summarized, isn't it?
You probably can't prevent it from being shared, so to prevent multiple use of it you would have to queue up the requests to be done one at a time. WynEaston's suggestion of having the servlet implement SingleThreadModel would help, but I believe the servlet spec allows servers to run multiple copies of a servlet that does that (as opposed to running a single copy in multiple threads).
Your other alternative is to rewrite the math in Java, or at least in some object-oriented language where you don't need global variables (which are the source of your problem). All right, I can already hear you saying "But that wouldn't be as fast!" Maybe not, but that isn't everything. Now you have a problem in queueing theory: do you want a single server that's fast, but jobs have to wait for it, or do you want multiple servers that aren't as fast, but jobs don't have to wait? That's a question you would have to evaluate based on the usage of your site, and it isn't an easy one.