If you have the Parallel Computing Toolbox then you can use spmd or parfeval to create multiple execution paths. However, if you invoked that from within a callback, both of those would still have the callback as the place to return to afterwards. One way around that is to have the main program uiwait() or waitfor() an event generated by the callback, so that you could at least get out of being within callbacks -- which makes a difference for whether other callbacks can interrupt.
However, the recommended method for handling something like this is to write the handling for the hardware in terms of callbacks such as BytesAvailableFcn that get called when the hardware has data available, or the similar callback that gets invoked when the previous data has been transmitted to the hardware. These callbacks would not run simultaneously, but the I/O would be handled asynchronously in such a setup, with it (at least in theory) being possible to put data into a buffer or send data from a buffer even while a callback for the other handware is running. You would generally prefer the callbacks to be short so the callbacks for the other hardware does not get queued, but not too short or you will waste too much time on the overhead of starting callbacks. Sometimes using timer callbacks can be a useful approach.
