There is absolutely no difference between a thread and a process on Linux. If you look at clone(2) you will see a set of flags that determine what is shared, and what is not shared, between the threads.
Classic processes are just threads that share nothing; you can share what components you want under Linux.
This is not the case on other OS implementations, where there are much more substantial differences.
Are lock, mutex, and semaphore for between threads or between processes?
You'll find examples of locking primitives for both situations. For example, pthread mutexes are used for mutual exclusion between threads of the same process. On the other hand, System V IPC (man svipc) semaphores can be used across processes. Filesystem-level locks (on files or parts of files) can also used to coordinate between multiple processes.
Must this "something" be some shared memory between multiple (threads or processes)?
Not necessarily shared memory. Any sort of resource can be protected with synchronization primitives. A piece of shared memory (shared between processes and/or threads) is perhaps the most common example, but other things like file-handles (locking a whole file, or parts of a file, or other sorts of "handles" to unique resources) and access to hardware devices are also possible.
If yes, does that mean lock, mutex, semaphore are only used for multiple threads of a process, not for multiple processes, because multiple processes don't share memory, while multiple threads of the same process do?
Well no. Processes can share memory. (And in fact most of them do, if only in a read-only fashion - pages containing shared library code are shared between processes. That doesn't need protection though. Copy-on-write shared mappings done when forking do need protection, but the kernel handles that transparently - this involves locks on shared memory mappings, which is conceptually a bit different from ordinary locks protecting a memory region/datastructure.)
Anything else that processes or threads can share (when at least one of them can write) needs protection/coordination, files and devices being the two most common I think.
Best Answer
From a
task_structperspective, a process’s threads have the same thread group leader (group_leaderintask_struct), whereas child processes have a different thread group leader (each individual child process).This information is exposed to user space via the
/procfile system. You can trace parents and children by looking at theppidfield in/proc/${pid}/stator.../status(this gives the parent pid); you can trace threads by looking at thetgidfield in.../status(this gives the thread group id, which is also the group leader’s pid). A process’s threads are made visible in the/proc/${pid}/taskdirectory: each thread gets its own subdirectory. (Every process has at least one thread.)In practice, programs wishing to keep track of their own threads would rely on APIs provided by the threading library they’re using, instead of using OS-specific information. Typically on Unix-like systems that means using pthreads.