CXPACKET SUSPENDED and NULL wait type I was was running the query in this article:

http://sqlity.net/en/708/why-cxpacket-waits-are-not-your-performance-problem/

To see what my threads were waiting on in regards to a suspended query with a wait type of CXPACKET.

However for the SPID in question threads that are running were showing wait types of NULL with every other thread in a SUSPENDED state with a wait type of CXPACKET.

I was expecting to one of the threads having some kind of wait type other than CXPACKET, can anyone explain to me what is happening in this situation?

Thanks
The CXPACKET was always the confusing wait type for younger DBAs and some predictably wrong reactions are generally expected. There are multiple acpects of the CXPACKLET wait type and I've tried in Troubleshooting the CXPACKET wait type in SQL Server article to bring on the table most of the reasons for high CXPACKET but also to explain the background of the CXPACKET, as the proper understanding of parallelism in SQL Server is the key for understanding

So for those who don't want to get in details, I will post the summary of the article here (but I would definitely suggest reading of the article for complete info about CXPACKET wait type):


  
  Do not set MAXDOP to 1, as this is never the solution
  Investigate the query and CXPACKET history to understand and    determine whether it is something that occurred just once or twice,
  as it could be just the exception in the system that is normally
  working correctly
  Check the indexes and statistics on tables used by the query and make    sure they are up to date
  Check the Cost Threshold for Parallelism (CTFP) and make sure that    the value used is appropriate for your system
  Check whether the CXPACKET is accompanied with a LATCH_XX (possibly    with PAGEIOLATCH_XX or SOS_SCHEDULER_YIELD as well). If this is the
  case than the MAXDOP value should be lowered to fit your hardware
  Check whether the CXPACKET is accompanied with a LCK_M_XX (usually    accompanied with IO_COMPLETION and ASYNC_IO_COMPLETION). If this is
  the case, then parallelism is not the bottleneck. Troubleshoot those
  wait stats to find the root cause of the problem and solution