The key zone of webrtc is the use of the lock.

Webrtc packages criticalsection, which can be used in windows and posix platforms.

The basic structure is as follows:

In the factory method, you are responsible for the creation of specific class objects, which can be called a simple factory model. A factory is responsible for the creation of all products, different products are created by inputting necessary parameters to the factory. Generally, the created products are related and inherited from an abstract class.
For CriticalSectionWrapper, You can regard it as a factory, which has a factory method CreateCriticalSection. It is responsible for creating specific instance objects. The input parameters are very special. It is a macro that creates windows objects in windows, posix environments, and posix objects.
In particular, the factory class is also the abstract base class of the product class, that is, the factory is responsible for producing the product, and it has the interface of the abstract product.
If you look at the alternative scheme, you can put the Enter and Leave methods into another abstract class as the base class of a specific product. The factory method returns the pointer of the base class.

The Code is as follows: abstract class, with a factory Method

class CriticalSectionWrapper { public:  // Factory method, constructor disabled  static CriticalSectionWrapper* CreateCriticalSection();  virtual ~CriticalSectionWrapper() {}  // Tries to grab lock, beginning of a critical section. Will wait for the  // lock to become available if the grab failed.  virtual void Enter() = 0;  // Returns a grabbed lock, end of critical section.  virtual void Leave() = 0;};

Specific factory methods

CriticalSectionWrapper* CriticalSectionWrapper::CreateCriticalSection() {#ifdef _WIN32  return new CriticalSectionWindows();#else  return new CriticalSectionPosix();#endif}

The two sub-classes are responsible for creating locks on different platforms.

class CriticalSectionPosix : public CriticalSectionWrapper { public:  CriticalSectionPosix();  virtual ~CriticalSectionPosix();  virtual void Enter();  virtual void Leave(); private:  pthread_mutex_t mutex_;  friend class ConditionVariablePosix;};

class CriticalSectionWindows : public CriticalSectionWrapper { public:  CriticalSectionWindows();  virtual ~CriticalSectionWindows();  virtual void Enter();  virtual void Leave(); private:  CRITICAL_SECTION crit;  friend class ConditionVariableWindows;};

The implementation code is simple and will not be pasted out. Basically, it is the initialization of the constructor, the release of the destructor, and the lock and unlock operations of the enter and leave respectively.

I don't feel that libjingle's talk/base is concise. That uses another idea. By naming the class name and method name, we can achieve the same purpose of calling different platforms.

It will be used as a library in the future. It will help us do a good job of cross-platform ....

To put it simply, the two modes of simple factory and factory method are different:

Simple factory mode:

A factory method is used to create all objects. When a product is added, the upper-layer factory method needs to be changed. Another idea of registration can be adopted: maintain a linked list in the factory class. When a user registers a new product
Add a new product to the linked list without changing the upper abstraction layer.

Factory method mode:
Delays object creation to sub-classes. The sub-factory is responsible for creating specific product classes.
There is an abstract factory class, and there is a factory interface, each factory needs to implement this interface to create a specific product, the application factory method is usually to create a product
Yes. All products have an abstract base class. In this way, the return value of the abstract factory can be set as an abstract product class pointer for customers to use.
The customer may need to instantiate a specific factory to create a specific product.