I don't understand what is it described in the page for thread synchronization
https://www.techopedia.com/definition/24349/thread-synchronization

Two or more than two threads can be share resource

I don't understand what are the critical resource

 

A "critical resource" is an abstract concept that can literally represent anything in a hardware or software system. Let us use the example of a log file, where system events are logged. The rule is that any system component can make an entry to the log file, but only ONE system component has that privilege at a time. So, a component must acquire the log file, make the entry, and release the log file. In this manner only one system component has the ability to modify the log file at every instant of time.

 

Let us use the example of a log file, where system events are logged. The rule is that any system component can make an entry to the log file, but only ONE system component has that privilege at a time. So, a component must acquire the log file, make the entry, and release the log file. In this manner only one system component has the ability to modify the log file at every instant of time.

Let us take the example where two threads controlling a DC motor.

Is this a thread synchronization ?

 

Let us take the example where two threads controlling a DC motor.

Is this a thread synchronization ?

Would that scenario make any logical sense? If so, that same rule might apply. That is, two threads can control the motor, but only one of them can do so at each instant of time. What happens if the motor is running, and nothing is controlling it?

 

What happens if the motor is running, and nothing is controlling it?

Would that make any sense logically?

 

Would that make any sense logically?

I don't think so, but that could happen in a multi-tasking system in which two different threads were allowed to control the motor. There might have to be additional rules such as the motor can only be acquired or released when it is stopped. You could for example distinguish between daytime and nighttime operation. We're talking about hypothetical situations in which a "critical resource" needs to be shared. They don't necessarily need to make sense, but they need to be rational.

 

I don't think so, but that could happen in a multi-tasking system in which two different threads were allowed to control the motor. There might have to be additional rules such as the motor can only be acquired or released when it is stopped. You could for example distinguish between daytime and nighttime operation. We're talking about hypothetical situations in which a "critical resource" needs to be shared. They don't necessarily need to make sense, but they need to be rational.

More likely, a rule stating, "a thread can only interact with the motor if it has a higher priority than the other threads controlling it." Some register would have to be assigned to show the priority of the thread currently controlling it and how to handle exceptions when a tread is refused control of the motor. Emergency stop would likely be given a very high priority on a core with few (if any) other tasks.

 

More likely, a rule stating, "a thread can only interact with the motor if it has a higher priority than the other threads controlling it." Some register would have to be assigned to show the priority of the thread currently controlling it and how to handle exceptions when a tread is refused control of the motor. Emergency stop would likely be given a very high priority on a core with few (if any) other tasks.

All reasonable rules for controlling a motor in an MT environment.

 

Let us take the example where two threads controlling a DC motor.

Is this a thread synchronization ?

Sure, you would need synchronization but usually the threads are controlling different aspects a the motor system that acts as a servo. One thread could the torque/current loop that regulates physical motor shaft acceleration movements in response to another thread that controls shaft speed in response to another thread that controls shaft positioning. One typically writes the software for these types of functions using hardware interrupts and atomic hardware registers that sequentially trigger and synchronize the needed loop steps to minimize software based synchronization using classic thread based constructs.

https://www.machinedesign.com/autom...icle/21828131/whats-and-whys-of-control-loops

Position — the location of one part referenced to some other physical point within the application. For example, a point on an indexing table relative to a drill head, or a point on a linear slide in relation to an inserter.

Speed — usually defined in revolutions per minute (rpm), radians/sec (rad/sec), or some other measure of velocity with respect to time.

Torque — generally defined by the electrical current flowing through the motor, which is indicative of the torque delivered by the motor.

 

Two tasks with the same priority share a single LED.The first task flashes the LED at 200 ms. The second task flashes the LED at 300 ms.

Does the LED need to be protected, if not why not?

 

Two tasks with the same priority share a single LED.The first task flashes the LED at 200 ms. The second task flashes the LED at 300 ms.

Does the LED need to be protected, if not why not?

It depends on what behavior you expect the LED to execute over the course of time. If you don't care about the behavior, then you don't need to protect it.

 

It depends on what behavior you expect the LED to execute over the course of time. If you don't care about the behavior, then you don't need to protect it.

Is there any condition in which the LED can be protected? There is no such situation in my mind right now.

 

Is there any condition in which the LED can be protected? There is no such situation in my mind right now.

The only one that makes any kind of sense to me it to alternate the control of the LED between the two tasks. The external behavior of the LED is that it would switch between the two blink rates in such a way that there would be no stutter-stepping at the changeover points.

 

Is there any condition in which the LED can be protected? There is no such situation in my mind right now.

Sure, there error indicators that use an LED as the error code display device (as a number of fast blinks) while the LED also serves as a normal activity monitor as a regular slow blink.

When the LED machine state is in the 'error' mode' you would lock out the 'activity' mode state of the LED blink functionality.

 

The only one that makes any kind of sense to me it to alternate the control of the LED between the two tasks. The external behavior of the LED is that it would switch between the two blink rates in such a way that there would be no stutter-stepping at the changeover points.

When the LED machine state is in the 'error' mode' you would lock out the 'activity' mode state of the LED blink functionality.

Please suggest me how to do experiments for thread synchronization ? ESP32, arduino ide

This is my code it flash single LED with two different rates 500ms and 800ms

/* Include FreeRTOS APIs and defines */
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/timers.h"

const int RED = 4;

void setup()
{
   Serial.begin(115200);
   pinMode(RED, OUTPUT);
  
  xTaskCreatePinnedToCore(Task1, "Task1", 1000, NULL, 1, NULL, 0);   
  xTaskCreatePinnedToCore(Task2, "Task2", 1000, NULL, 1, NULL, 0); 
 
}   

void Task1( void * parameter )
{
 
  for(;;)
  {
     digitalWrite( RED, HIGH);
     vTaskDelay( 500 );
     digitalWrite( RED, LOW);
     vTaskDelay( 500 );
  }
}

void Task2( void * parameter )
{
  for(;;)
  {
            digitalWrite(RED, HIGH);
            vTaskDelay( 800 );
            digitalWrite(RED, LOW);
            vTaskDelay( 800 );
  }
}

void loop() {}