In computer programming, a mutex is a program object that allows multiple program threads to share the same resource, such as file access, but not simultaneously. When a program is started, a mutex is created with a unique name.

IMPLICIT – implied though not plainly expressed.
In other words, implied, hinted at, suggested, insinuated.

IMPLICIT LOCK:
Objectivity will implicitly obtain the appropriate locks for your application
AT THE POINT at which they are needed. An operation that reads an object will obtain a read lock; an operation that modifies an object will obtain a write lock.

The Objective-C language level synchronization uses the mutex.

The @synchronized directive is a convenient way to create mutex locks on the fly in Objective-C code. The @synchronized directive does what any other mutex lock would do—it prevents different threads from acquiring the same lock at the same time. In this case, however, you do not have to create the mutex or lock object directly. Instead, you simply use any Objective-C object as a lock token, as shown in the following example:

The object passed to the @synchronized directive is a unique identifier used to distinguish the protected block. If you execute the preceding method in two different threads, passing a different object for the anObj parameter on each thread, each would take its lock and continue processing without being blocked by the other.

If you pass the same object in both cases, however, one of the threads would acquire the lock first and the other would block until the first thread completed the critical section.

As a precautionary measure, the @synchronized block implicitly adds an exception handler to the protected code. This handler automatically releases the mutex in the event that an exception is thrown. This means that in order to use the @synchronized directive, you must also enable Objective-C exception handling in your code. If you do not want the additional overhead caused by the implicit exception handler, you should consider using the lock classes

EXPLICIT – stated clearly and in detail, leaving no room for confusion or doubt.

EXPLICIT LOCK:
Some applications, however, may need to reserve access to all required resources in advance. Reasons for doing so might be to secure required access rights to the necessary objects before beginning an operation, or to prevent other sessions from modifying objects critical to the operation.

An application needing to reserve access to all required objects in advance can explicitly lock objects. Suppose an application needs to calculate a value based upon the state of many objects at a specific point in time. Although the application cannot check all of the necessary objects simultaneously, it can achieve the same effect by “freezing the state of the objects” and then checking them in sequence. Explicit locking “effectively freezes the objects”, because no other session can modify them as long as they are locked.

For example, NSLock: