Yes, you can use both SPs without causing path thrashing as long as all your ESX hosts are configured to use the MRU multipathing policy. Remember, even though both SPs are active, they will only be active for the LUNS that you assign to them. So if LUN1 has a preferred controller of SPA and LUN2 has a preferred controller of SPB, and you configure 10 ESX hosts to access both luns and configure them to use a multipathing policy of MRU...of which you should, they will all access LUN1 through SPA and LUN2 through SPB. What makes your array truly active/passive is that when LUN1 has a preferred controller of SPA, it can not be accessed by SPB. SPB can only access LUN1 when it becomes the preferred controller...and that happens in three cases.
1. You manually change the preferred controller(SP) for LUN1 to SPB
2. A failure happens on a hba/switch/path, so the host multipathing software tells the ARRAY to change LUN1s preferred controller to SPB (as MRU will do for you)
3. SPA in the array fails so SPB will automatically make itself the preferred controller. Using MRU, all your ESX hosts will be notified to start accessing LUN1 on SPB.
Here is a good explaination of path thrashing posted by Jhanekom that I'm copying from this thread http://communities.vmware.com/message/874826#874826
Path thrashing is when the active path for a LUN switches rapidly from one storage controller to the next. It generally results in severely degraded performance and, in extreme cases, a number of instability issues. Path thrashing does not occur with only one ESX host or single-controller storage systems.
In ESX, path thrashing most frequently occurs if the ESX multipathing policy is set to "fixed", and the storage controllers are active/passive at the back-end ("esxcfg-mpath -l" lists half the paths as "on", and the other half as "standby".) The other case is when there is a configuration issue on the storage controller, specifically that the controllers are really active/passive, but report themselves as being active/active ("esxcfg-mpath -l" returns all paths' status as "on".)
In the first case, if ESX servers are set up to have different preferred paths (i.e. Server 1 prefers to use controller A, Server 2 prefers to use controller B), they may cause the active/passive controllers to switch a LUN from one controller to the next constantly. This is a configuration problem on the ESX server and can be corrected by setting the path policy back to the default of MRU. (LUNs on active/passive controllers should always use MRU; active/active LUNs can use either MRU or Fixed, but uses fixed by default.)
The second case is a configuration issue on the storage controller and needs to be corrected there. In this case, the ESX servers will have no way of determining which is the correct path and will try to communicate on the first available one. The storage controller will then fail the path over to the controller being target. The feature that needs to be disabled is sometimes called AVT (auto-volume transfer) and you'll see mention to it in /var/log/vmkwarning if the problem occurs. In most cases, setting the host type to "cluster" resolves this, but you need to check your SAN vendor's documentation for this one.
