In a word, no. Diamond never uses polling for I/O transfers. Whenever a thread has to wait for a channel transfer, it is descheduled and other threads continue to execute. The waiting thread will resume when the completion of the transfer is signalled by an interrupt.

The mistaken idea that Diamond polls probably derives from an incorrect statement in a 2006 article by M. Raulet et al, Rapid Prototyping for Heterogeneous Multicomponent Systems: An MPEG-4 Stream over a UMTS Communication Link (EURASIP Journal on Applied Signal Processing Volume 2006, Article ID 64369, 1-13, DOI 10.1155/ASP/2006/64369).

This article stated that '[in 3L Diamond,] data transfers are realized using DMA, but without any computation parallelism which is nearly equivalent to polling technique.' This is simply a misunderstanding of how Diamond works. A thread that is waiting for a channel transfer is indeed blocked and performs no more computation until the transfer has completed, but other threads continue to run, providing the 'computation parallelism' that is claimed to be absent. There is no polling (or its equivalent) in Diamond communications.

This is rather like asking, why do I need a high-level language? The strict answer is that you can make do without tools to help you build applications, but you will be making your task an order of magnitude harder.  If you decide not to use 3L Diamond to build a multiprocessor application you will have to do all the work yourself, including things like:

• loading all the processors, including ones remote from the host PC
• keeping control of all the separate modules needed to load your application
• starting your application in a synchronised way
• managing communications, possibly including deadlock-free message routing
• writing your own device drivers
• explicitly managing all memory allocation
• writing your own multithreading support or using something that is likely to be less efficient than Diamond's
• inventing a host communication mechanism
• being prepared to rewrite your source if the configuration changes
• being prepared to make major changes if the underlying hardware changes
• supporting multiple source versions for all hardware and configuration variations
• handling all of the underlying hardware peculiarities (unexpected cache behaviour, for example)
• ... and many more.

Diamond can do all of this for you. 3L works closely with hardware vendors and puts a great deal of time, effort, and experience into optimising all aspects of the system to give you the best results.

See the more complete article here.