Sponsored Content
Full Discussion: Behavior of pthreads
Top Forums Programming Behavior of pthreads Post 302071427 by jim mcnamara on Wednesday 19th of April 2006 11:44:10 AM
Old 04-19-2006
Simple answer - do not expect the same behavior for this kind of application across hardware and OS. 10.20 is an older OS, so it may schedule threads as lightweight processes, like earlier versions of Linux.

I don't know this to be true, I'm just making a suggestion.

You can't guarantee which thread runs first unless you set mutexes to control "who" can run.

Why do you want a certain order?
 

10 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

PThreads

Can anyone explain me how to use pthread_key_create() , pthread_setspecific(), pthread_getspecific() and pthread_key_delete () routines in pthreads. Kindly state by an example. (3 Replies)
Discussion started by: S.P.Prasad
3 Replies

2. Programming

pthreads

Does any one no of some good web site which will explain about how to program using pthreads in a UNIX enviroment? (6 Replies)
Discussion started by: fishman2001
6 Replies

3. Programming

pthreads

howcome that pthtreads spawn 2 extra processes? I'm kind of new with pthreads but fork() did not act like this. Anyone who can give me a technical explanation of what happends with mother / daughter processes? Best regards Esaia. (2 Replies)
Discussion started by: Esaia
2 Replies

4. Programming

PThreads

I have created a thread program, it is attached. My problem is that I need to loop this program multiple times, and basically reset everything including the threads created previously. I try to loop the program, the first run is fine, as always, but the second run of the program, the initialize... (0 Replies)
Discussion started by: justgotthis
0 Replies

5. UNIX for Dummies Questions & Answers

Question on Pthreads

How to give superuser privileges while setting the attributes like pthread_attr_setschedpolicy( )?? Even with normal user mode ,it is working fine for me.But in man pages, they have specied that to set the scheduling policy as SCHED_FIFO, the process should have superuser privileges. (0 Replies)
Discussion started by: yashavant.a
0 Replies

6. HP-UX

pthreads

Hi! I'm linking my hpux code using -lpthread (gcc), yet it references libpthread_tr.1, the debug version of the pthread lib. How do I force it to use pthreads? Thanks, :) (3 Replies)
Discussion started by: zackz
3 Replies

7. Programming

Problem with pthreads

hi i have a code: I found that after exiting from child thread memory isn't freed. I commented everything which is "some actions" here, so thread's function contains only two lines. But it doesn't help. What do I do wrong? Thanks a lot (3 Replies)
Discussion started by: sery0ga
3 Replies

8. UNIX for Advanced & Expert Users

Pthreads-Conditional variables

Hello, consider a bunch of threads which want to execute a while loop in parallel but after each iteration of while loop, we need a synchornization.That is, we have a global count varibale which is equal to zero at beginig of each iteration and at the end of each iterartion this variable... (0 Replies)
Discussion started by: Behnaz
0 Replies

9. Programming

MultiThreading using Pthreads

Situation: i have multiple pthread_create calls like this: pthread_create(...., ThreadFunc1,.....); pthread_create(...., ThreadFunc2,.....); . . which i am using to create multiple threads.All the "ThreadFunc<i>" functions are actually calling same function "Receive" of a class using same... (3 Replies)
Discussion started by: Sastra
3 Replies

10. Programming

Idleness with pthreads

Hello, I am writing a threaded program using the pthread library in linux. I have a master thread that needs to control worker threads, in particular, it has to be able to ensure that none of the worker threads will be running for a specified amount of time, even if the worker threads are... (7 Replies)
Discussion started by: andres625
7 Replies
SWI(9)							   BSD Kernel Developer's Manual						    SWI(9)

NAME
swi_add, swi_sched -- register and schedule software interrupt handlers SYNOPSIS
#include <sys/param.h> #include <sys/bus.h> #include <sys/interrupt.h> extern struct ithd *tty_ithd; extern struct ithd *clk_ithd; extern void *net_ih; extern void *softclock_ih; extern void *vm_ih; int swi_add(struct ithd **ithdp, const char *name, driver_intr_t handler, void *arg, int pri, enum intr_type flags, void **cookiep); void swi_sched(void *cookie, int flags); DESCRIPTION
These functions are used to register and schedule software interrupt handlers. Software interrupt handlers are attached to a software inter- rupt thread, just as hardware interrupt handlers are attached to a hardware interrupt thread. Multiple handlers can be attached to the same thread. Software interrupt handlers can be used to queue up less critical processing inside of hardware interrupt handlers so that the work can be done at a later time. Software interrupt threads are different from other kernel threads in that they are treated as an interrupt thread. This means that time spent executing these threads is counted as interrupt time, and that they can be run via a lightweight context switch. The swi_add() function is used to register a new software interrupt handler. The ithdp argument is an optional pointer to a struct ithd pointer. If this argument points to an existing software interrupt thread, then this handler will be attached to that thread. Otherwise a new thread will be created, and if ithdp is not NULL, then the pointer at that address to will be modified to point to the newly created thread. The name argument is used to associate a name with a specific handler. This name is appended to the name of the software interrupt thread that this handler is attached to. The handler argument is the function that will be executed when the handler is scheduled to run. The arg parameter will be passed in as the only parameter to handler when the function is executed. The pri value specifies the priority of this interrupt handler relative to other software interrupt handlers. If an interrupt thread is created, then this value is used as the vec- tor, and the flags argument is used to specify the attributes of a handler such as INTR_MPSAFE. The cookiep argument points to a void * cookie. This cookie will be set to a value that uniquely identifies this handler, and is used to schedule the handler for execution later on. The swi_sched() function is used to schedule an interrupt handler and its associated thread to run. The cookie argument specifies which software interrupt handler should be scheduled to run. The flags argument specifies how and when the handler should be run and is a mask of one or more of the following flags: SWI_DELAY Specifies that the kernel should mark the specified handler as needing to run, but the kernel should not schedule the software interrupt thread to run. Instead, handler will be executed the next time that the software interrupt thread runs after being scheduled by another event. Attaching a handler to the clock software interrupt thread and using this flag when scheduling a software interrupt handler can be used to implement the functionality performed by setdelayed() in earlier versions of FreeBSD. The tty_ithd and clk_ithd variables contain pointers to the software interrupt threads for the tty and clock software interrupts, respec- tively. tty_ithd is used to hang tty software interrupt handlers off of the same thread. clk_ithd is used to hang delayed handlers off of the clock software interrupt thread so that the functionality of setdelayed() can be obtained in conjunction with SWI_DELAY. The net_ih, softclock_ih, and vm_ih handler cookies are used to schedule software interrupt threads to run for the networking stack, clock interrupt, and VM subsystem respectively. RETURN VALUES
The swi_add() function returns zero on success and non-zero on failure. ERRORS
The swi_add() function will fail if: [EAGAIN] The system-imposed limit on the total number of processes under execution would be exceeded. The limit is given by the sysctl(3) MIB variable KERN_MAXPROC. [EINVAL] The flags argument specifies either INTR_ENTROPY or INTR_FAST. [EINVAL] The ithdp argument points to a hardware interrupt thread. [EINVAL] Either of the name or handler arguments are NULL. [EINVAL] The INTR_EXCL flag is specified and the interrupt thread pointed to by ithdp already has at least one handler, or the interrupt thread already has an exclusive handler. SEE ALSO
ithread(9), taskqueue(9) HISTORY
The swi_add() and swi_sched() functions first appeared in FreeBSD 5.0. They replaced the register_swi() function which appeared in FreeBSD 3.0 and the setsoft*(), and schedsoft*() functions which date back to at least 4.4BSD. BUGS
Most of the global variables described in this manual page should not be global, or at the very least should not be declared in <sys/interrupt.h>. BSD
October 30, 2000 BSD
All times are GMT -4. The time now is 04:52 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy