If yes, is it similar concept as to thread vs process in Computer Science? Thanks. I am thinking to create massive threads to finish some heavy-lifting work. If thread is lighter and can do the same job as the process, thread is better choice with less impact on the server?

Process:

• An executing instance of a program is called a process.
• Some operating systems use the term 'task' to refer to a program that is being executed.
• A process is always stored in the main memory also termed as the primary memory or random access memory.
• Therefore, a process is termed as an active entity. It disappears if the machine is rebooted.
• Several process may be associated with a same program.
• On a multiprocessor system, multiple processes can be executed in parallel.
• On a uni-processor system, though true parallelism is not achieved, a process scheduling algorithm is applied and the processor is scheduled to execute each process one at a time yielding an illusion of concurrency.
• Example: Executing multiple instances of the 'Calculator' program. Each of the instances are termed as a process.

Thread:

• A thread is a subset of the process.
• It is termed as a 'lightweight process', since it is similar to a real process but executes within the context of a process and shares the same resources allotted to the process by the kernel.
• Usually, a process has only one thread of control – one set of machine instructions executing at a time.
• A process may also be made up of multiple threads of execution that execute instructions concurrently.
• Multiple threads of control can exploit the true parallelism possible on multiprocessor systems.
• On a uni-processor system, a thread scheduling algorithm is applied and the processor is scheduled to run each thread one at a time.
• All the threads running within a process share the same address space, file descriptors, stack and other process related attributes.
• Since the threads of a process share the same memory, synchronizing the access to the shared data within the process gains unprecedented importance.

------------------------------
mvp morgan
------------------------------

You can sort of draw some similarities to these concepts, but not exactly. All processing done in TM1, regardless of how they are initiated, are threads running in the the TM1 executable (process). The manner in which the process is initiated determines how much "overhead" is used. In my mind you can group process executions into 2 groups, Externally Initiated (via a Broker or Agent) and Internally Initiated. Broker/Agent processes require more (sometimes trivial) overhead. 

Broker/Agent/External:

• Requires authentication to create its first session, session is shareable for future calls.
• Caller is responsible for managing the response
• Caller is responsible for managing the state of the process (Running, Completed, etc)

Internal

• Session is inherited from the TI that calls it, no auth required
• Everything is managed by TM1.
• In v11 there is no thread management ability, processes run and complete with no response. 

------------------------------
Ryan Clapp
------------------------------

Thanks, Ryan. So, I guess only RUNPROCESS falls into Internal Category and others go to Broker/Agent/External?

------------------------------
mvp morgan
------------------------------

Original Message:
Sent: Thu February 09, 2023 09:53 AM
From: Ryan Clapp
Subject: Is RUNPROCESS/ASYNC ENDPOINT creating a lightweight thread in the backend compared with normal TI process?

You can sort of draw some similarities to these concepts, but not exactly. All processing done in TM1, regardless of how they are initiated, are threads running in the the TM1 executable (process). The manner in which the process is initiated determines how much "overhead" is used. In my mind you can group process executions into 2 groups, Externally Initiated (via a Broker or Agent) and Internally Initiated. Broker/Agent processes require more (sometimes trivial) overhead. 

Broker/Agent/External:

• Requires authentication to create its first session, session is shareable for future calls.
• Caller is responsible for managing the response
• Caller is responsible for managing the state of the process (Running, Completed, etc)

Internal

• Session is inherited from the TI that calls it, no auth required
• Everything is managed by TM1.
• In v11 there is no thread management ability, processes run and complete with no response. 

------------------------------
Ryan Clapp
------------------------------

Hi mvp morgan,

When you call the RUNPROCESS command from a TI, it creates a new thread. I recommend that you test it to see if it meets your requirements. Testing RUNPROCESS should be much easier than testing TM1RunTI, which can also achieve parallel processing.

You have mentioned that you want to create massive threads so I assume that you will run many threads in parallel. However, if you create more threads than what your processor cores can handle at a given time, the extra threads will have to wait anyway. I think RUNPROCESS can help you speed up some tasks and increate CPU utilization until all CPU cores are fully utilized.

Thanks,

Kong

------------------------------
Kong Intrasinghathong
Master Consultant
QueBIT Consulting
https://quebit.com
------------------------------