Your question suggests the application knows and manage its own PID and should pass it to the kernel for the latter to know how to do its job. This is a common misconception. The way this information flows is actually the other way around. A process doesn't need to know or store its process id, file descriptor tables and similar. If it wants to get information about them, it needs to retrieve it from the kernel using system calls like
ioctl and the like.
While the kernel is made of a big bunch of source code lines, it is not a single program running on its side, with userland programs being living on the other side and sending requests to the kernel like say a web browser is sending requests to a web server. The system call parameters and return value are not the unique information flowing between the application and the kernel and all the low level information about every thread and process, whatever their state (running, waiting, sleeping…), is stored in the kernel memory.
You should see a large part of the kernel code like a big library, kind of linked with every running process on the system. When a process (actually a thread) performs a system call, it just dive into that special library and get super powers for a small period of time. But it is still the very same thread, so the kernel has all the information required to identify and manage the running thread like its owner, group, pid, file descriptors tables, and so on because it is precisely the kernel (here the scheduler) which assigns threads to available (v)CPUs.