-4

Is the thread in MS Windows with C++ a time slice or the execution of a function or both?

A thread is executing a function which is a block of code inside an outer loop. If you send a signal (via a global variable) to break from the outer loop. The function returns, but what happens to the running thread assuming it is a time slice of execution?

user207421
  • 305,947
  • 44
  • 307
  • 483
Hatems
  • 39
  • 1
  • 9
  • 1
    The thread is destroyed. Why do you say it is "inside an outer loop?" – OldProgrammer Apr 16 '16 at 20:51
  • I meant the function it self has loop (I call it outer loop) and inside this loop there could be many blocks of code and many other loops may be even nested loops etc, obviously if we break this outer loop the function returns. – Hatems Apr 16 '16 at 21:01
  • @Hatems Not all thread functions conform to that description, and the point doesn't seem relevant to your question. Neither does C++. Your question is basically meaningless. – user207421 Apr 16 '16 at 21:35
  • @EJP I gave an example. I do not I think I can find an example which can fit all types of functions. The point is to send a signal of the function being executed in a thread and this function is returned prematurely, and what I described in my comment is just an example of a function being terminated by breaking a loop. Functions may be terminated by many other methods. – Hatems Apr 16 '16 at 21:57
  • @EJP It seems you did not understand either the question or the topic or both. Thread coding is language dependent. The thread library in C++ is quite different from the thread library by Microsoft, very different from pThread lib, or Boost lib etc. Scheduling may be the same or may be different. Your comment is either wrong or meaningless or both. – Hatems Apr 17 '16 at 01:01
  • @Hatems Threading at bottom is a system call that starts an operating system thread and transfers control to an application-supplied subroutine. Everything a language does is built on top of it. There is nothing in your question that is language-specific. Thread scheduling is implemented by the operating system, as your own quotation from Microsoft in another comment confirms. You are in no position to remark on other people's understanding of this topic. – user207421 Apr 17 '16 at 01:59
  • @EPJ You say "The executable can create as many threads as it likes." then you say "system call that starts an operating system thread and transfers control to an application-supplied subroutine" who is confused? – Hatems Apr 17 '16 at 10:13
  • @Hatems *You* are confused. There is no contradiction there. An executable program can create as many threads as it likes, *by calling that system call.* Consider a TCP server that runs forever and creates a new thread per accepted connection. You can't know many threads is it going to create in advance. Consider a program that asks the user how many threads to create, and then creates that many threads. You can't know how many threads is that going to create in advance either. And none of this has anything to do with your question. – user207421 Apr 17 '16 at 13:45
  • @EJP You are certainly confused. This is not about how many threads. You did not understand the question. It is about one simple thread executing one function and this function is terminated prematurely without using abort() or terminate() or Suspend() etc. Where is here how many threads. or whether the app,exe "can create as many as he likes" of threads. The question is none of these. you invented this story of "as many threads as it likes" I am not interested nor my question about how many threads an app can create and whether he likes them or not. – Hatems Apr 17 '16 at 18:06
  • @Hatem You asked, and I quote *verbatim*, "does the scheduler in Windows need to know how many threads there are in app.exe ...?", and that is what I am addressing. But this all appears to be mere pointless trolling. It's unclear why you ask the question if you think you already know the answer, – user207421 Apr 17 '16 at 19:03

2 Answers2

2

Neither.

If your scheduler is set to a time-slice algorithm then the time-slice represents when and how long your thread will run.

A thread is an object that manages a block of executable code that can be scheduled. Typically, as part of thread creation you pass a function pointer to that block of code. When the "job" of the executable code is done the thread is destroyed.

Pemdas
  • 543
  • 2
  • 9
  • I meant with respect to windows and not with respect to any other type OS. As windows is time-based sharing operating system. I will try to edit the title. – Hatems Apr 16 '16 at 21:09
  • 1
    It doesn't matter what the operating system is the principle is still the same. – Pemdas Apr 16 '16 at 21:10
  • Assume we have an application app.exe in Windows (I want to exclude any preemptive OS for the time being) The scheduler in Windows is time slice based and cooperative. Does the scheduler in Windows needs to know how many threads are there in app.exe and how they will run in app.exe before the start of execution of app.exe? – Hatems Apr 16 '16 at 21:26
  • @Hatems 'How many threads are there' is meaningless. It isn't fixed. The executable can create as many threads as it likes. 'How they will run' doesn't mean anything either. – user207421 Apr 16 '16 at 21:34
  • @EJP OK. My understanding from your comment is that the Windows schedular does not see the threads inside app.exe? is this right? If so in that case who schedule the threads inside app.exe? – Hatems Apr 16 '16 at 21:43
  • @Hatems I didn't say that, or anything resembling it. The scheduler *implements* the threads. What I said was that the number of threads 'in the app.exe' is meaningless, because it isn't fixed. So the scheduler cannot see it in advance, because it doesn't exist in advance. – user207421 Apr 16 '16 at 21:53
  • 1
    @Hatems: *I want to exclude any preemptive OS for the time being* - Windows *is* a preemptive OS. The 16-bit versions were cooperative, but that was two decades ago. – Harry Johnston Apr 16 '16 at 22:07
  • @Harry Johnston, From Microsoft: "The system assigns time slices in a round-robin fashion to all threads with the highest priority. If none of these threads are ready to run, the system assigns time slices in a round-robin fashion to all threads with the next highest priority. If a higher-priority thread becomes available to run, the system ceases to execute the lower-priority thread (without allowing it to finish using its time slice), and assigns a full time slice to the higher-priority thread" This Context Switching. See this http://stackoverflow.com/questions/11602395 – Hatems Apr 17 '16 at 00:42
  • @Hatems 'Ceases to execute' *is* pre-emptive, and all thread switching is context switching. You seem terribly confused. – user207421 Apr 17 '16 at 01:52
  • @EJP new definition for preemptive, should be entered into the Wikipedia. When the normal time slice is up the thread also cease to execute until its next time slice starts. – Hatems Apr 17 '16 at 10:18
  • @Hatems There is no 'new definition for pre-emptive'. What there is is a poorly expressed Wikipedia article about it, tangentially containing a misleading remark about context switching, which I have corrected, which provides another instance of [Wikipedia is not a reliable source](https://en.m.wikipedia.org/wiki/Wikipedia:Wikipedia_is_not_a_reliable_source). In any case you haven't previously cited it in your question. You can trawl the Internet for misinformation as much as you like, but it doesn't change the correct answer to your question. – user207421 Apr 17 '16 at 10:48
  • An preemptive OS is an OS whose scheduler has no time slices mechanism in any fashion. The scheduler queues all threads (tasks) according to priority alone. Each thread is executed until either completion or interrupted by a higher priority new thread. So if a thread is executing in an infinite loop (for ex) and no other thread with higher priority is available in the scheduler, then no other thread will have any chance to execute. Windows is based on time slicing, Of course there are priority levels and the scheduler can evict execution, but only temporarily for a maximum of one time slice – Hatems Apr 17 '16 at 18:27
  • @Hatem. I would describe that as a *purely* pre-emptive operating system, and we still need a term for thread scheduling with pre-emption *a la* Windiws, where there are both time slices and priority-based pre-emotion. But I've had enough of this. – user207421 Apr 17 '16 at 19:11
  • @Hatems: that's not the usual definition. See for example http://www.riscos.info/index.php/Preemptive_multitasking or any of the other top Google links. Or the accepted answer in the question you linked to: "Preemption is the act of interrupting a process without its involvement." The process doesn't have to take any action when the timeslice expires, and that's what makes it a preemptive OS. – Harry Johnston Apr 17 '16 at 21:03
  • @Harry Johnston Interrupt (hardware and/or software) is at the heart of every processor and every OS on planet. There is no OS without interrupt. So if we classify OSes on the basis of interrupt we have an issue. if we classify OSes on basis of how the scheduler works, then we see different OSes. One approach is time slicing which is not present in all OSes, after all OSes were invented before the name. So there will be always variations in definitions and how we classify OSes. Can a thread/process gets involved in its interruption? How? Scheduler initiates all interruptions based on criteria – Hatems Apr 17 '16 at 21:27
  • @Hatems: it's certainly true that it's all about how the scheduler works. 16-bit Windows was an example of a cooperative (non-preemptive) OS. So was the old MacOS, prior to Mac OS X. In a cooperative OS, there aren't any timeslices. Whichever thread is running continues to run until it explicitly tells the operating system to perform a context switch. In 16-bit Windows, for example, a process (16-bit Windows didn't have threads) continues to run until it explicitly calls Yield() or GetMessage() or one of a few other functions I don't recall offhand. – Harry Johnston Apr 17 '16 at 21:56
  • (Device interrupts are handled differently, by the way. The CPU or OS transferring control to a device driver's interrupt routine typically doesn't involve the scheduler and therefore is not usually considered to be a context switch.) – Harry Johnston Apr 17 '16 at 21:58
0

In 32-bit and 64-bit Windows, every thread runs a specified function. Conceptually speaking, the initial thread of a new process runs the application's main function, and every additional thread runs a function specified by the programmer when the thread is created. See the documentation for CreateThread; the lpStartAddress argument specifies the function for the thread to run.

(In fact, each thread also runs operating system code, and usually runtime library code as well, but that's an implementation detail that doesn't matter for our purposes.)

Conceptually, when any particular thread is running on a particular CPU core, it might stop for either of two reasons: because the thread has stopped running altogether, or because of a context switch. In the case of a context switch, the thread will be started up again at a later time, and from the thread's point of view everything will look the same as it did when it was interrupted.

(In fact, the OS may also interrupt the thread in order to run device driver or other operating system code. This doesn't involve a context switch; the device driver code runs in the context of the interrupted thread, which is one of the reasons device drivers are hard to write.)

Here are some of the reasons the thread might stop running altogether ["exit"]:

  • The function the thread was created to run has exited.

  • The thread calls ExitThread().

  • Some other thread calls TerminateThread().

Here are some of the reasons there might be a context switch:

  • The thread's timeslice has expired.

  • Another thread with a higher priority has become ready to run.

  • The thread calls Sleep() or one of the wait functions.

It's hard to tell what you're trying to ask, so this may not have addressed it. But perhaps it will clarify things enough to allow you to ask your question in words I can understand.

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
  • I understand new things now, Thank you. What I am really after is the following: I am writing multi threaded application in C++ and CLR with WinForm GUI, It also has some C++ code outside CLR and WinForm. I had a lot of difficulties in restarting a none GUI thread. If I make the thread so the GUI remains responsive, the thread would not start again whether it completed or interrupted. If I make the none GUI thread so that the GUI is NOT responsive, I can not interrupt the thread, but the thread can start from fresh after its completion. – Hatems Apr 19 '16 at 04:12
  • So I tried the first case to exit the thread using a global flag. The thread status shows it stopped. So I want to know why the thread can not restart again without restarting the whole application. – Hatems Apr 19 '16 at 04:12
  • Once a thread has exited, it can't be restarted. But you can start a *new* thread that runs the same function. – Harry Johnston Apr 19 '16 at 04:31
  • Is this irrespective how the thread exited, (completion or prematurely)? Do you mean by starting new thread, you have another button for example and another delegate for the same function etc..? if this this the case what about if you want to start the same function many times manually or in a loop? Thank you. – Hatems Apr 19 '16 at 10:59
  • (1) yes, it is irrespective of why the thread exited, but keep in mind that a thread whose timeslice expired or was preempted by a higher priority thread hasn't exited and will continue running when it next gets a timeslice. (2) I'm not sure what you mean by "button" in this context. (3) I'm not familiar enough with CLR to discuss the impact of threading on delegates. That might more sensibly be a new question, aimed at CLR experts; you should probably provide an [mcve] to demonstrate your problem. – Harry Johnston Apr 19 '16 at 19:44
  • I will comment that if you are using threading correctly, running the same function many times in a loop (either in the same thread or in different threads) isn't a problem, and I'm not sure why you think it is. The thread doesn't have to exit before the timeslice expires, if that's what you're thinking. Remember, when the timeslice expires, the thread's context is saved, and after a short delay it will continue to run from where it left off. – Harry Johnston Apr 19 '16 at 19:49