| legalize+jeeves@mail.xmission.com (Richard): May 15 11:18PM [Please do not mail me a copy of your followup] Vir Campestris <vir.campestris@invalid.invalid> spake the secret code >That's why threads first turned up (says wikipedia) on an IBM mainframe >back in the '60s. And weren't supported by Windows until XP (if I have >it right) in about 2001. Windows NT, released in 1993, had threads from the beginning. Windows XP was the first "consumer" version of Windows that had threads and is based on NT, just as Windows 2000 was before that. (I consider Windows 2000 the first "consumer" version of NT, although XP was considered by MS to be the first one that was ready for consumers as it was compatible with more consumer software from 9x.) -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Robert Wessel <robertwessel2@yahoo.com>: May 15 06:32PM -0500 On Tue, 15 May 2018 21:50:33 +0100, Vir Campestris >reading your other posts is perhaps your problem. >And the only Windows that ran on that damn brain-damaged '286 (1) wasn't >even vaguely related to the Windows we have today. Windows NT 3.1 fully supported threads, circa 1993. It's been a core part of the Win32 API, since day one, only the Win32s subset (unloved and mostly unused) didn't support threads. While some *nix had threads fairly early, there was considerable resistance to the concept in the overall community. |
| David Brown <david.brown@hesbynett.no>: May 16 08:57AM +0200 On 16/05/18 01:18, Richard wrote: >> back in the '60s. And weren't supported by Windows until XP (if I have >> it right) in about 2001. > Windows NT, released in 1993, had threads from the beginning. That was my thought too. It was also multi-processing, but threads were always much cheaper than processes in Windows. I can't remember if the Win9x series supported threads - I /think/ they did, but I am not sure. Multiple threads were not so popular in those days as all PC's were single core - SMP was only used on big NT servers (in the Windows world). > consider Windows 2000 the first "consumer" version of NT, although XP > was considered by MS to be the first one that was ready for consumers > as it was compatible with more consumer software from 9x.) I am not sure how they define "consumer" - perhaps "the version usually pre-installed on computers sold to the unwashed masses". I certainly had W2K at home - but I always installed OS's myself, rather than using pre-installed setups. NT 4.0 was when NT became popular for professional work, but it was not much used by consumers (who were stuck with "Windmill" at the time). |
| David Brown <david.brown@hesbynett.no>: May 16 09:01AM +0200 On 16/05/18 01:32, Robert Wessel wrote: > Windows NT 3.1 fully supported threads, circa 1993. It's been a core > part of the Win32 API, since day one, only the Win32s subset (unloved > and mostly unused) didn't support threads. Actually, Win32s was quite well loved by those of us with Win3.x and big programs! It was also part of the promise of running Windows programs on OS/2, which in the days of OS/2 4.0 was way ahead of anything Windows could provide. But when NT 4.0 came out, MS had to do something to force OS/2 users to move to Windows - so instead of updating the support for OS/2 to full Win32, it killed it off, including Win32s. > While some *nix had threads fairly early, there was considerable > resistance to the concept in the overall community. I vaguely remember a war going on over at least two different types of threading in Linux. I was not programming for Linux in those days, I merely observed the war from a distance. |
| Ian Collins <ian-news@hotmail.com>: May 16 08:01PM +1200 On 16/05/18 19:01, David Brown wrote: > I vaguely remember a war going on over at least two different types of > threading in Linux. I was not programming for Linux in those days, I > merely observed the war from a distance. No one was - Linux wasn't around in those days! -- Ian |
| Robert Wessel <robertwessel2@yahoo.com>: May 16 03:18AM -0500 On Wed, 16 May 2018 08:57:23 +0200, David Brown >did, but I am not sure. Multiple threads were not so popular in those >days as all PC's were single core - SMP was only used on big NT servers >(in the Windows world). Yes, Win95, 98 and ME all supported threads, but only a single processor (core). Only for Win32 code. Win16 code continued to run on a single (system) thread with cooperative multitasking between the processes. For completeness, you could have threads in the VMM, although you were pretty far removed from normal Windows coding at that point. Certainly one important use of threads is exploiting multiple cores, although that's not the only reason to use threads. |
| David Brown <david.brown@hesbynett.no>: May 16 10:27AM +0200 On 16/05/18 10:01, Ian Collins wrote: >> threading in Linux. I was not programming for Linux in those days, I >> merely observed the war from a distance. > No one was - Linux wasn't around in those days! LinuxThreads was from 1996, but was awkward and inefficient (it basically made a process per thread - allowing you to compile code designed for Posix threads, but it was not giving you the advantages of multi-threading over multi-processing). There were two competing thread implementations for Linux that fixed this - meaning there were three noticeably different types of threading for a while. Eventually NPTL won one and everyone lived happily ever after. Coincidentally, 1996 was also the year NT 4.0 came out. So Linux certainly /was/ around at that time, and already popular in some environments (like HPC), but the "Linux thread wars" were a little later. |
| David Brown <david.brown@hesbynett.no>: May 16 10:43AM +0200 On 16/05/18 10:18, Robert Wessel wrote: > that point. > Certainly one important use of threads is exploiting multiple cores, > although that's not the only reason to use threads. Agreed - once you get used to thread programming, they are useful for all kinds of things. But prior to SMP (again, I'm talking about the DOS/Windows world) PC's got faster by having faster single threaded performance, and software generally followed that route. Event-driven Windows programming gave you a kind of cooperative multithreading within your program. It was only with the rise of multiple cores where programmers /had/ to use multiple threads to improve performance that multi-threaded programming really took off in the Windows world. You can see a difference in the kind of networking and file I/O coding styles that was common on Windows, compared to *nix programming. In the Windows world, asynchronous I/O was vital to being able to do work while waiting for data. In *nix, you would be more likely to use a thread and blocking I/O, because it is often simpler logic in the code - asynchronous I/O (and "select") was harder, and used when you had a lot of things going on at once to get higher efficiency. In small embedded systems, you generally only have a single core - but RTOS-based systems can easily have a dozen or more threads. It is simply a nice way to organise the program. |
| boltar@cylonHQ.com: May 16 08:47AM On Tue, 15 May 2018 17:39:18 +0200 >On 15/05/18 16:39, boltar@cylonHQ.com wrote: >and processes. You can do it with locks, mutexes, semaphores, shared >memory, message passing, file IO, pipes, and many other ways. Shared memory certainly has its uses, but the rest of Sys V IPC is rarely used in my experience any more. It was always clunky and didn't play well with the rest of the posix subsystems. >Any of these can give you deadlocks, livelocks, races, and other >problems if you handle them incorrectly. All of them can work fine if >you handle them correctly. The underlying principles are not different. Well they are, because pipes and sockets are buffered interfaces that you can read or not read at your leisure. Not reading them has no adverse effects upon the application wrt to blocking etc. >- like locks or shared memory. Similarly, there may be a tendency in >multi-processing setups to use less efficient but easier to understand >solutions like pipes. So if you don't really understand how to deal They're the standard method since you can multiplex on the file descriptor or use non blocking IO or even set SIGIO. Using SysV IPC gets you into the exact sort of race condition/locking issues that you have with threads. >scalability, flexibility, etc., rather than ignorance or prejudice. Given that I've been writing system and application software for unix since the early 90s I may be prejudiced but I am certainly not ignorant on the topic. >about them. (That also includes an understanding of what a small part >of a big field any one developer will ever meet.) I don't know /your/ >experience, but I'm guessing it is pretty low in this area. I worked on some ticketing machines once which had multiple CPUs, all of which ran discrete programs, not OS's. >> days from industrial control systems to routers to as you mentioned, >> smartphones. >Your wild guesses don't count for much. Well since there's no way of proving it one way or the other there's little point arguing the toss about it. >usually more efficient than spawning new processes or threads. But >efficiency is not always the main concern in finding the best solution. As the rapid rise of inefficient bloatware libraries that cater to people with limited ability demonstrates. > A good developer does not think one architecture is always "right", or >another architecture is always "wrong" - you look at what is the best >choice for the task in hand. Can't disagree there. |
| boltar@cylonHQ.com: May 16 08:50AM On Tue, 15 May 2018 21:50:33 +0100 >Yeah, right. >That's why threads first turned up (says wikipedia) on an IBM mainframe >back in the '60s. And weren't supported by Windows until XP (if I have Really? How do you think all the various GUI events were run in the background then while your application ran its main thread? Or do you remember having to - for example - explicitely program the cursor to flash in a text box? |
| boltar@cylonHQ.com: May 16 08:54AM On Wed, 16 May 2018 08:57:23 +0200 >> Windows NT, released in 1993, had threads from the beginning. >That was my thought too. It was also multi-processing, but threads were >always much cheaper than processes in Windows. Since windows couldn't (and AFAIK still doesn't) support fork(), spawning a child process in windows to accomplish a subtask is pretty futile as it had to start from main() again with presumably a load of command line parameters required to tell it what to do. God knows how you'd pass any binary data in, I guess a temporary file. Ugh. |
| boltar@cylonHQ.com: May 16 08:56AM On Wed, 16 May 2018 09:01:18 +0200 >I vaguely remember a war going on over at least two different types of >threading in Linux. I was not programming for Linux in those days, I >merely observed the war from a distance. Up until kernel 2.2 or 2.4, I forget which, threads were actually seperate processes in disguise with a wrapper library hiding all the nasty implementation details. |
| Robert Wessel <robertwessel2@yahoo.com>: May 16 04:00AM -0500 On Wed, 16 May 2018 10:27:13 +0200, David Brown >So Linux certainly /was/ around at that time, and already popular in >some environments (like HPC), but the "Linux thread wars" were a little >later. No the debate I was referring to preceded that. This was before widespread implementation of threads in Unix, and mostly (completely?) before Linux. IIRC, from the mid eighties to the early nineties, give or take. A large portion of the Unix community took the position that "threads are evil, processes are all you need". Suggesting that Unix *should* have threads often provoked a rude response. There were certainly exceptions, mainly from *nix vendors who made big (MP) machines. |
| David Brown <david.brown@hesbynett.no>: May 16 11:20AM +0200 > it had to start from main() again with presumably a load of command line > parameters required to tell it what to do. God knows how you'd pass any > binary data in, I guess a temporary file. Ugh. Correct - Windows does not support fork(). You can do spawn, which (IIUIC) is like fork then exec, and you can, I think, do a vfork(). This is one of the key points where multi-processing on Windows is significantly less efficient than on Linux (or other *nix), and of the main reasons you don't use a "fork off lots of child processes to handle connections" model for server code in Windows as you often do in *nix. Of course it is still entirely possible to use multiple processes on Windows - you just have to work a little harder to hide the messy details. If you use Python, for example, you can do your parallel coding using the "threading" module or the "multiprocessing" module, with almost identical interfaces for each, and work in the same simple way on Linux or Windows. You pay a performance penalty for the abstraction, especially if you use a model that does not fit well with the OS, but it all works with minimal programmer effort. |
| David Brown <david.brown@hesbynett.no>: May 16 11:23AM +0200 On 16/05/18 11:00, Robert Wessel wrote: > *should* have threads often provoked a rude response. > There were certainly exceptions, mainly from *nix vendors who made big > (MP) machines. Ah, well, that was before my time. I didn't start programming until about 1980, and as an eight-year-old I didn't have much access to Unix systems :-( |
| boltar@cylonHQ.com: May 16 09:43AM On Wed, 16 May 2018 11:23:21 +0200 >Ah, well, that was before my time. I didn't start programming until >about 1980, and as an eight-year-old I didn't have much access to Unix >systems :-( My school in the 70s had a timesharing system called Equinox something or other. God knows what OS it ran but it allowed us to program Basic on the terminals. Had a habit of crashing quite often IIRC so the teacher used to sit next to the machine ready to press the reset button. |
| Ian Collins <ian-news@hotmail.com>: May 16 10:26PM +1200 On 16/05/18 21:00, Robert Wessel wrote: > or take. A large portion of the Unix community took the position that > "threads are evil, processes are all you need". Suggesting that Unix > *should* have threads often provoked a rude response. Indeed! Some of the first C++ I wrote (early 90s) was a "thread" wrapper library around SunOS LWPs. It provided a better platform for modeling our embedded RTOS than earlier attempts using processes. That was probably where I got the thread bug. -- Ian. |
| Paavo Helde <myfirstname@osa.pri.ee>: May 16 02:00PM +0300 > Well they are, because pipes and sockets are buffered interfaces that you > can read or not read at your leisure. Not reading them has no adverse effects > upon the application wrt to blocking etc. Buffered interfaces are great for distributing and synchronizing work, that's the reason whay they are used extensively in multi-threaded programming. In C++ they are often called message queues and can be implemented easily by using for example a std::deque, a std::mutex and a std::condition_variable. For example, the Windows windowing infrastructure is built upon such multithread-enabled queues (window event queues). >> multi-processing setups to use less efficient but easier to understand >> solutions like pipes. So if you don't really understand how to deal > They're the standard method since you can multiplex on the file descriptor or Multiplexing on a file descriptor is similar to a wait on a std::condition_variable. A drawback is that it's less portable since in Windows select() et al only work on limited types of resource descriptors. > use non blocking IO or even set SIGIO. Using non-blocking IO means polling which is either a resource hog or causes slower response times. So it is suited only for some special situations. Signals are also not so portable and they are tricky to use in C++ anyway. The most sane way to deal with signals in C++ (sigwait()) basically assumes creating a new thread in the first place and translating the signals to inter-thread events. It's also non-portable of course. Also, most C++ code goes into libraries which are expected to work in arbitrary client applications and cannot just hijack the process-wide signal mechanisms. |
| David Brown <david.brown@hesbynett.no>: May 16 03:56PM +0200 > Well they are, because pipes and sockets are buffered interfaces that you > can read or not read at your leisure. Not reading them has no adverse effects > upon the application wrt to blocking etc. Of course it does. It is certainly conceptually easier to work with queues of various sorts when synchronising data between parallel code streams. One of the important uses of locks and mutexes is to implement queues, fifos, message buffers, etc. But it is easy to deadlock processes using queues - if process P1 waits for data coming in on Q1 before sending out on Q2, and process P2 waits for data coming in on Q2 before sending out on Q1. Queues (pipes, sockets, whatever) can be used to simulate locks and mutexes, and therefore can be used to get the same deadlocking. Pretty much /any/ synchronisation method can be used to implement any other one - they are therefore equivalent in terms of the things you can do with them, including the mistakes you can make. But they differ significantly in terms of efficiency for various tasks, convenience, and the ease of getting particular tasks right, and the difficulty of getting particular tasks wrong. So you /can/ deadlock with pipes - you are just a good deal less likely to do it accidentally. This is also why message passing and queues are often a good way to handle inter-thread communication, not just inter-process communication. >> scalability, flexibility, etc., rather than ignorance or prejudice. > Given that I've been writing system and application software for unix since > the early 90s I may be prejudiced but I am certainly not ignorant on the topic. Your high prejudice against threads suggests you are ignorant, or at least inexperienced, in using them. Of course there is sense in using what you know - if a particular architecture works for you and your needs, then there may not be any point in looking at other solutions. Just don't make the mistake of thinking that your way is the /only/ way, or that everyone else is wrong. >> experience, but I'm guessing it is pretty low in this area. > I worked on some ticketing machines once which had multiple CPUs, all of > which ran discrete programs, not OS's. You make that sound like something from long ago. Small RTOS's were less used in older times - they need a bit more processing power and memory than you used to get with 8051 and similar devices. But as you can get ARM core microcontrollers for $0.30, developers have the freedom to use them for flexibility. >> Your wild guesses don't count for much. > Well since there's no way of proving it one way or the other there's little > point arguing the toss about it. I invite you to google a bit. You probably won't get accurate numbers (I couldn't find any), but you will see enough to get an idea of the trends. >> efficiency is not always the main concern in finding the best solution. > As the rapid rise of inefficient bloatware libraries that cater to people > with limited ability demonstrates. Tell me, do you take your car when you go to the shops? Isn't it a bit inefficient to move a couple of tons of metal when all you really want to do is move a few pints of milk and a loaf of bread? You do it because it is far more convenient to the user. When you want to move 20 tons of milk to deliver to the shop, on the other hand, you use a different ratio for better efficiency. It's the same in development. Sometimes the emphasis should be on developer time, sometimes it should be on processor run time. Usually, it is somewhere in between. >> another architecture is always "wrong" - you look at what is the best >> choice for the task in hand. > Can't disagree there. Ah, agreement at last! |
| scott@slp53.sl.home (Scott Lurndal): May 16 01:57PM >Shared memory certainly has its uses, but the rest of Sys V IPC is rarely >used in my experience any more. It was always clunky and didn't play well >with the rest of the posix subsystems. Consider the history. shmat/semops were introduced from a branch of unix within AT&T (PWB/Unix, IIRC). However, there are now posix versions of both that fit better into the unix namespace philosophy. >Well they are, because pipes and sockets are buffered interfaces that you >can read or not read at your leisure. Not reading them has no adverse effects >upon the application wrt to blocking etc. Writes to pipes and fifos may block if the reader doesn't read. |
| scott@slp53.sl.home (Scott Lurndal): May 16 01:59PM >Using non-blocking IO means polling which is either a resource hog or >causes slower response times. So it is suited only for some special >situations. One can also use lio_listio, aio_read, aio_write, et alia. I used lio_listio extensively (with list sizes exceeding 100 buffers at times) in a port of Oracle to an MPP machine. |
| David Brown <david.brown@hesbynett.no>: May 16 03:59PM +0200 > other. God knows what OS it ran but it allowed us to program Basic on the > terminals. Had a habit of crashing quite often IIRC so the teacher used to > sit next to the machine ready to press the reset button. The first time one of my schools got a computer, I was in charge of it - aged 12. I knew far more about it than any of the teachers. |
| scott@slp53.sl.home (Scott Lurndal): May 16 02:03PM >widespread implementation of threads in Unix, and mostly (completely?) >before Linux. IIRC, from the mid eighties to the early nineties, give >or take. Digital Unix and SVR4/MP both had threading models in the early 80's/90's. About the same time, POSIX 1003.4 was being developed (called realtime extensions, which included pthreads). > A large portion of the Unix community took the position that >"threads are evil, processes are all you need". I was there, deep in the standards process in the early 90's and what you say does not ring true. There may have been such voices, but they did not encompass a "large portion of the unix community". >*should* have threads often provoked a rude response. >There were certainly exceptions, mainly from *nix vendors who made big >(MP) machines. Well, that was me :-). |
| Sky89 <Sky89@sky68.com>: May 15 11:20PM -0400 On 5/15/2018 11:12 PM, Sky89 wrote: > Thank you, > Amine Moulay Ramdane. This library version 1.66 was optimized more, and now it is a powerful and great library. Thank you, Amine Moulay Ramdane. |
| dianejbabin@gmail.com: May 14 10:49PM -0700 On Friday, March 13, 2009 at 1:33:38 AM UTC+5:30, Zeh Mau wrote: > this is very common when designing a problem. > I appreciate your comments. > Zeh Mau https://groups.google.com/d/topic/soc.culture.hongkong/di4zlwKq7CY |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment