This series of three articles helps the developers involved in the tedious process of migrating/porting the OS/2 system drivers and applications to Linux. It provides a one-to-one mapping of various OS/2-to-Linux calls related to threads, IPC, memory management, timer handling, file handling, and so on. In addition, it captures the various preprocessor directives and compiler/linker options that can be mapped from OS/2 to Linux.
From OS/2 to Linux, Part 1; Threads, Mutexes, and Semaphores
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I think the article’s distinction between thread and processes is questionable/confusing?
I appears to me that OS/2 is like OpenVMS and therefore also WNT. I that model you have a process as a container for one or more threads. In Linux there is no process container for threads. Every thread is also a process and visa versa and is called a task to avoid confusion. But since Linux does task creation by copying and modifying an existing task rather than building from scratch as the other OS’es do then task instantiation in Linux is cheap which is why it is also called a lightweight process.
Does anyone know if Linux supports *installed* application extensions (so’s=dll’s) as other OS’es do e.g. such when a task needs to execute code in a so then the first time it checks to see if that so is already in global memory and if so then it uses it.
The article should be titled “Making OS/2 backward compatiable with *nix”. In reality that is the direction IBM has chosen to send many of its customers if they are silly enough to sign on !!
> Does anyone know if Linux supports *installed* application extensions (so’s=dll’s)
I don’t understand what you mean with “installed”, but from the man pages of my gentoo box:
dladdr, dlclose, dlerror, dlopen, dlsym, dlvsym – programming interface to dynamic linking loader
Well you are a bit confussed yourself, linux supports some level of threading with posix like thread packages which allows for kernel threads. This means that not every thread is a process, you can have a bunch of kernel threads contained as a process.
The stuff about dlls has nothing to do with threading really, it is implemented as shared libraries in most unix systems. It has to do with several processes being able to share a portion of common code, like functions and what not so that memory requirements are preserved. But it has to be done at link time, and it is not done dynamically (I do not think any OS does that due to the overhead that would generate).
Process creation in Linux is not really how you described, that was thread spawning… and no Linux is not the only system that does that. Generating a process like you describe would not really buy you much.
Actually, I think Claus’s description was quite accurate. Linux doesn’t really have threads. It just has processes. Processes are created by clone()’ing an existing process, which does copy the state of the existing process. Normally, clone() gives a process a new address space, new file descripters, etc. But clone() takes parameters which let you share address spaces, so ‘threads’ in Linux are just processes that share the same address space. I’m pretty sure the pthreads libs like NPTL implement pthread_create() and whatnot in terms of this underlying mechanism.
*installed* is the term used by OpenVMS with an app extension (or for that matter any other file) registered as a known entity in shared memory using the DCL INSTALL command and to which needy processes can link (rather than each pull their own copy from disk into their private address spaces). If the dlopen() supported the file mmap’ed with MAP_SHARED then that’s what I was going for.
IBM says, look we failed in the OS market, quickly lets go for linux so our current and former competetors cant get money
As far as I know in the 2.5 and on kernels, the pthreads are implemented as kernel threads. And clone() will generate a proper thread, where most of the state is just a pointer to the state descriptor for the parent process rather than a straight cloning. I believe in the old days of Linux, and a lot of Unices they did the quick and dirty everything is a light process approach. The thread switch has been greatly improved due to the real thread/proceess differenciation.
Or maybe I am just having a mental fart and I have been too corrupted by solaris. But I seem to recall that now linux will do some sort of kernel threads.
Am I wrong here?
I agree with you up to the spinlocks, for I believe the spinlock implementation in OS/2 is caluclated using the offset of the RNG2k4 unit present on all newer FIFO type BIOS flash roms, which leads to some portablity problems when brining an application over to the new UML/SOAP application standard present in the newer USB cup warmers.
Did you calculate for the offset introduced by XML parsing? This significant overhead is often semaphored by otherwise well-meaning programmers. Such a contemporary oversight often leads to compiler anorexia, but with Firefox, together we can save the world.
Shared objects work automatically. So all (non-statically linked) applications use the same (in memory) copy of the object. It is read-only memory so it works without problems.
Task initialization is cheap because linux uses copy-on-write for fork so it doesn’t really copy anything. If it wasn’t then task initialization would be expensive since fork literally means copy the whole thing and continue on the next instruction.
I knew COW (copy-on-write). But I had the impression that it is limited to working for tasks for which one is the descendant of the other. What happens if the tasks are say siblings? Parent task A which does not run x.so forks both task B and C which both run x.so. Does B and C share the same in-memory copy of x.so? They can on OpenVMS but only after using the INSTALL command.
so’s are shared between all running processes whether they are related or not. I think the sharing is only for programs executed by the same user, but I am not sure about that.
From what I can tell .so’s are mmap’ed with MAP_PRIVATE, producing COW semantics. I don’t know why the objects wouldn’t be shared among all processes. Especially considering that that’s sort of the point of both mmap() and shared libraries.
Unless I’m wrong, the “disappearance” of OS/2 has nothing to do with the rise of Linux. It was IBM that decided to slow it’s development, long before Tux became widely known. Also, isn’t it premature to characterize Linux as the operating system of the 21st century ?
when you can have complicated (LINUX.)
IBM executives are always going the WRONG way. Linux is just hype.
“IBM executives are always going the WRONG way. Linux is just hype.”
Yeah that is why IBM has all those billions in the bank….
Yes, obviously there is a direct relationship of billions in bank to corporate omniscience.
“Yes, obviously there is a direct relationship of billions in bank to corporate omniscience.”
Obviously….
I think there is a much stronger case for such supposition, vs. being always wrong and have billions in the bank. But hey I guess ya’ll know something that the rest of the world and especially IBM seems to be missing!