Sponsored Content
Special Forums UNIX and Linux Applications High Performance Computing Memory Barriers for (Ubuntu) Linux (i686) Post 302430614 by gorga on Friday 18th of June 2010 06:27:48 AM
Old 06-18-2010
Quote:
Originally Posted by fpmurphy
Huh? NPTL is a 1:1 threading model. NGPT is an M:N threading model. Of course the kernel is involved.
I was referring to the older GNU Portable Threads...

GNU Pth - The GNU Portable Threads

"Pth doesn't require any kernel support, but can NOT benefit from multiprocessor machines."

Hmm...

"In practice, this is no problem, because multiprocessor systems are rare, and portability is almost more important than highest concurrency."

(Written some time ago I presume)

You're referring to Next Generation Posix Threads developed by IBM though. I'm not sure but wasn't this abandoned in favour of simpler 1:1 threading in NPTL? But anyway, I needed something with more control than was on offer with something featuring a standard posix api.
 

4 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Memory-waste in Ubuntu/Debian?

I have 512 mem on this laptop, though 'top' tells me I only have 380. However, Ubuntu is using 288 mb of memory, when I only have 3 terminals, running lynx, vim(for this file) and (of course) top. Considering it I have lynx running a 600 page txt file, which of course would eat some memory but 300?... (0 Replies)
Discussion started by: riwa
0 Replies

2. Linux

i686, x86 64, ppc

Hi, i am quite new to linux. I am interested in fedora linux distro. Fedora Project I dont know which one to choose, either i686, x86 64 or ppc. I prefer a live cd, coz its easy to use. And what is the difference between "Fedora Desktop Live Media" and "Fedora KDE Live Media". (3 Replies)
Discussion started by: superblacksmith
3 Replies

3. Programming

Getting the total virtual memory for ubuntu in c++

Hi guys , i need to get the total virtual memory in ubuntu but i need to write a C++ code for that, any idea on how to go about doing it? any references? or website that i can refer to ? (6 Replies)
Discussion started by: xiaojesus
6 Replies

4. Ubuntu

XP and Linux (Ubuntu) on same disk, Can I install Ubuntu on not-yet partitioned portion of disk?

My PC (Esprimo, 3 yeas old) has one hard drive having 2 partitions C: (80 GB NTFS, XP) and D: (120 GB NTFS, empty) and and a 200 MB area that yet is not-partitioned. I would like to try Ubuntu and to install Ubuntu on the not-partitioned area . The idea is to have the possibility to run... (7 Replies)
Discussion started by: C.Weidemann
7 Replies
PCL(3)							    Portable Coroutine Library							    PCL(3)

NAME
co_create, co_call, co_resume, co_delete, co_exit_to, co_exit, co_current - C coroutine management SYNOPSIS
#include <pcl.h> coroutine_t co_create(void *func, void *data, void *stack, int stacksize); void co_delete(coroutine_t co); void co_call(coroutine_t co); void co_resume(void); void co_exit_to(coroutine_t co); void co_exit(void); coroutine_t co_current(void); DESCRIPTION
The Portable Coroutine Library (PCL) implements the low level functionality for coroutines. For a definition of the term coroutine see The Art of Computer Programming by Donald E. Knuth. Coroutines are a very simple cooperative multitasking environment where the switch from one task to another is done explicitly by a function call. Coroutines are a lot faster than processes or threads switch, since there is no OS kernel involvement for the operation. This document defines an API for the low level handling of coroutines i.e. creating and deleting coroutines and switching between them. Higher level functionality (scheduler, etc.) is not covered. Functions The following functions are defined: coroutine_t co_create(void *func, void *data, void *stack, int stacksize); This function creates a new coroutine. func is the entry point of the coroutine. It will be called with one arg, a void *, which holds the data passed through the data parameter. If func terminates, the associated coroutine is deleted. stack is the base of the stack this coroutine will use and stacksize its size in bytes. You may pass a NULL pointer for stack in which case the memory will be allocated by co_create itself. Both, stack and stacksize are aligned to system requirements. A stacksize of less then 4096 bytes will be rejected. You have to make sure, that the stack is large enough for your coroutine and possible signal handlers (see below). The stack will not grow! (Exception: the main coroutine uses the standard system stack which may still grow) On success, a handle (coroutine_t) for a new coroutine is returned, otherwise NULL. void co_delete(coroutine_t co); This function deletes the given coroutine co. If the stack for this coroutine was allocated by co_create it will be freed. After a coroutine handle was passed to co_delete it is invalid and may not be used any more. It is invalid for a coroutine to delete itself with this function. void co_call(coroutine_t co); This function passes execution to the given coroutine co. The first time the coroutine is executed, its entry point func is called, and the data parameter used during the call to co_create is passed to func. The current coroutine is suspended until another one restarts it with a co_call or co_resume call. Calling oneself returns immediately. void co_resume(void); This function passes execution back to the coroutine which either initially started this one or restarted it after a prior co_resume. void co_exit_to(coroutine_t co); This function does the same a co_delete(co_current()) followed by a co_call would do. That is, it deletes itself and then passes execution to another coroutine co. void co_exit(void); This function does the same a co_delete(co_current()) followed by a co_resume would do. That is, it deletes itself and then passes execution back to the coroutine which either initially started this one or restarted it after a prior co_resume. coroutine_t co_current(void); This function returns the currently running coroutine. Notes Some interactions with other parts of the system are covered here. Signals First, a signal handler is not defined to run in any specific coroutine. The only way to leave the signal handler is by a return statement. Second, the signal handler may run with the stack of any coroutine, even with the stack of library internal coroutines which have an undefined stack size (just enough to perform a kernel call). Using and alternate stack for signal processing (see sigaltstack(2)) is recommended! Conclusion: avoid signals like a plague. The only thing you may do reliable is setting some global variables and return. Simple kernel calls may work too, but nowadays it's pretty hairy to tell, which function really is a kernel call. (Btw, all this applies to normal C programs, too. The coroutines just add one more problem) setjmp/longjmp The use of setjmp(2)/longjmp(2) is limited to jumping inside one coroutine. Never try to jump from one coroutine to another with longjmp(2). DIAGNOSTICS
Some fatal errors are caught by the library. If one occurs, a short message is written to file descriptor 2 (stderr) and a segmentation violation is generated. [PCL]: Cannot delete itself A coroutine has called co_delete with it's own handle. [PCL]: Resume to deleted coroutine A coroutine has deleted itself with co_exit or co_exit_to and the coroutine that was activated by the exit tried a co_resume. [PCL]: Stale coroutine called Someone tried to active a coroutine that has already been deleted. This error is only detected, if the stack of the deleted corou- tine is still resident in memory. [PCL]: Context switch failed Low level error generated by the library in case a context switch between two coroutines failes. SEE ALSO
Original coroutine library at http://www.goron.de/~froese/coro/coro.html . GNU Pth library at http://www.gnu.org/software/pth/ . AUTHOR
Developed by Davide Libenzi < davidel@xmailserver.org >. Ideas and man page base source taken by the coroutine library developed by E. Toernig < froese@gmx.de >. Also some code and ideas comes from the GNU Pth library available at http://www.gnu.org/software/pth/ . BUGS
There are no known bugs. But, this library is still in development even if it results very stable and pretty much ready for production use. Bug reports and comments to Davide Libenzi < davidel@xmailserver.org >. GNU
1.6 PCL(3)
All times are GMT -4. The time now is 01:25 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy