Two or more threads executing concurrently require synchronization if and only if at least one of the threads accesses and modifies one or more variables (write access) accessed by the remaining threads (either read or write access). Therefore, if all of the threads access the same set of variables only for reading their values (read access), no synchronization is needed. You probably know that the access to variables by multiple threads when at least one of them writes at least one of the variables, must happen in a so-called critical section (or critical region) of code. You then synchronize the access by providing mutual exclusion using for instance a Posix mutex lock. This permits concurrent execution of multiple threads, so that the execution preserves correctness when updating one or more of the variables involved.
Of course, concurrent execution of multiple threads is the most efficient way of writing code in general. However, you may also imagine a different execution, in which the operations associated to each thread are executed sequentially and not concurrently, one after the other, in an order that is strictly equivalent to a concurrent, correct execution. This is called serialization of execution. What does it mean "strictly equivalent" ? Serialization must provide as a requirement exactly the same results that will be provided by a concurrent, correct execution. Note that there are multiple possible concurrent and correct executions, but the outcome must be one and only one.
Now, do you really want to use serialization to synchronize your threads ? The answer is no, because a serialized execution is in general slower than a concurrent execution (obvious, since execution is sequential and not concurrent). In practice, serialization just gives you a criterion for correctness. You want your threads to execute concurrently, for performance reasons, however, you must ensure that the outcome is correct independently of the actual concurrent execution that took place.
As an example imagine two threads accessing a variable which is the amount of money you have deposited in your bank. If both threads just want to read that amount of money, no issue arises. However, if one or both the threads want to modify that value, a problem arises and you need to synchronize the access. For instance, one thread may be depositing money to your account (you in your bank), and the other thread ma be withdrawing money from your account (your wife from an ATM). In these cases, access to the variable holding the amount of money must be synchronized. Serialization in this case is simple: you must either first withdraw the money and then add the money, or, vice-versa, you first add the money to your bank account and then withdraw the money. In both cases, serialization provides the correct outcome. To grant a correct outcome in the case of a concurrent execution, you must instead protect the variable using a mutex lock, so that access to the variable is mutually exclusive for both the threads. Otherwise, the value of the variable when accessed from both threads without proper synchronization is actually undefined, which is very bad for your money! You may, for example loose part or all of of your money.
Another type of synchronization is not related to mutual exclusion. Imagine, for instance, that one thread can execute its operations only after another thread has completed. Another example: a thread can execute only when a specific condition is true, and this condition depends on another thread (this includes the previous example, but is a more general requirement, based on the evaluation of a predicate).
For instance, you may synchronize threads in this way by using Posix mutex locks and condition variables.
Serialization has been thoroughly studied in the context of database transactions. A serialized schedule provides a criterion for correctness of execution of concurrent transactions in databases, and there are protocols that ensure proper synchronization (e.g., two-phase locking). But the concept applies equally well to threads as well.