same function called by events

Hi there. i have a wondering that might affect my application pretty much.
I have a function, lets call its

VB Code:

functionX(ByVal A() as byte)

I have as well three public subs that handle an event (when data is written on a specific com port) and they all three at some point might call functionX, with a different array of bytes each, as parameter.
Question: Is there a chance that functionX will be called by one of the subs, while its allready processing the data A() from previous call? Is there any possibility to have some kind of confusion of data there?

Thanks in advance

is it a multt-threaded application or a single thread.
If its a single threadeda application then it dont think it will happen as the event that captures the data from the com port calls functionX but the event probably wont fire again until functionx finishes

its single thread. however there are three events that can call functionX. So if event1 calls functioX, and before fucntionX finishes event2 calls functionX then we might have a problem? or not?

the whole concept with single thread is that it can only be doing one thing at the one time.
so event 2 will not be invoked (even though data will be coming in on the port) until event1's call to functionX is finished.

That's not strictly true because some objects raise, or can raise, their events in a worker thread implicitly. Examples include the Timers.Timer and FileSystemWatcher classes. It's worth making sure that the object(s) whose event you're handling doesn't do that. Those that do would have a SynchronisingObject property, or at least the two I mentioned do. If the SynchronisingObject is set then the thread that owns that object will be used to handle the events. If it's not set then a new thread will be created.

That said, it may still not be a problem that the same method is being executed on multiple threads simultaneously. Then again, it might. If there's a possibility of concurrent execution and that could cause interference then you would need to use thread synchronisation techniques. The most likely choice would be to simply wrap the contents of the method in a SyncLock block.

ok i see. thats pretty clear. i guess if the process handles different resources and data there wont be any confusion. i'll see what happens
thanks again