Yes of course
I have implemented a Java - Program, which starts on a laptop 3 threads. Those threads connect to the CC3000 and request a picture over HTTP. Therefore on the packet side, there are:
Laptop -> CC3000: request packet
CC3000 -> Laptop: picture in chunks of data (around 1400 bytes per chunk) response
The HTTP - Server on the CC3000 side is querying the CC3000 with select() and if something turns up (data received, send buffer free) it takes the corresponding action and due to the nature of select(), the send() and recv() should never block. If nothing happens the controller will do something else.
An internal test on the controller showed that under maximum throughput, the controller has around 2/3 of the time nothing to do, therefore the CC3000 is busy and under maximum load.
With the old firmware version, i had problems calling recv() and send() consecutively, as stated in this thread: http://e2e.ti.com/support/low_power_rf/f/851/t/235086.aspx
However the new firmware solved this problem and I expected an increased Throughput because i can call recv() and send() consecutively, but the throughput stayed the same.