we know that when TCP data is received with PSH set, it will immediately transfer the received data to the application.and let's when pushed data arrives the receiver side and the receiver application is not reading any data(busy with other tasks). then how does the receiver pass the data to its application process since the receiver's process is not even reading data?
The PSH flag causes the sender's stack to immediately send out the next data segment, without collecting more data. The receiver's stack doesn't wait for more data either and passes the segment's data to the application immediately[*1]. If the receiving application is slow or doesn't read the data at all, that's where it gets stuck. The PSH flag can't magically wake up a dead process.
Without PSH, sending small data chunks may be delayed when the sender (or receiver) stack waits for more data to fill up a segment (or buffer). This can significantly reduce processing and protocol overhead when data is produced only in small chunks.
If the PUSH flag is set, the data must be transmitted promptly to the receiver, and the PUSH bit will be set in the last TCP segment created from the buffer. If the PUSH flag is not set, the data may be combined with data from subsequent SENDs for transmission efficiency.
Note the similarity with URG that is something different still, as it signals the receiver stack to press URGent data that the application should process out of order.
A typical example for PUSH is a console application (telnet) that sends each key separately and would suffer severe lag without PUSH. URG can be used to signal a break / stop / reset in such an application: stop running output instead of outputting everything in line and then waiting for/processing the next user input.
[*1] While the PSH flag doesn't really make a difference for synchronous/blocking reading of a socket, it does for asynchronous processing where the stack may interrupt the receiving application. APIs and host/OS implementations are off topic here, however.