Sponsored Content
Full Discussion: Controlling child processes
Top Forums Programming Controlling child processes Post 50239 by DreamWarrior on Monday 19th of April 2004 06:26:03 PM
Old 04-19-2004
Quote:
Originally posted by forumGuy
It is actually a Operating system course and all the major topics mentioned we have studied; on an academic level I understand it, however implementation is something different. In regards to deadlocks I do not know if this helps, however the Bankers algorithm may be a start (lots of overhead and predefined info is needed). Do not beat yourself up about the deadlock issue even the big boys (Oracle) occasionally end up in this state and most Operating systems including UNIX ignore it. Do you know the type of deadlock that is being encountered i.e. mutual exclusion, hold and wait, circular waiting or non preemptive (Studied for a final, it is fresh in the noggin)?
FI
Actually I myself am not encountering any problems with deadlocks. Although I understand them quite well, and am familar with the banker's algorithm. However, I'm lucky in that I don't need it because I am in complete control of my resources and can simply generate (and strickly follow) locking rules that guarentee I won't deadlock.

In my case, this is simple. In the case of an OS or DB, it's not so simple because you're not in complete control over what the end interface (process/client) will request or do with the resources. Funny enough that in these circumstances the Banker's Algorithm is generally of no help because most of the time the OS/DB has no knowledge of what resources are going to (or ever will be) requested by the processes/clients that it is scheduling. Therefore, this renders the Banker's Algorithm useless, as it requires all processes to notify the scheduler of all its resource requirements before entering a "critical section" and unless the OS/DB places strict requirements on its interface (which they'd prefer not to do) they can deadlock and there's nothing that can be done about it besides detect it and tell the application that it must correct it.

In *nix, the EDEADLK errno is set in response to the failed system call that generated the potential deadlock. The application then can either die, release resources and try again, or just spin trying infiniately and hoping that the condition is corrected (which is unlikely).

In Oracle, the deadlock is detected and broken by automatically "rolling back" the client having less work done at the time of detection. Afterwhich, the client can attempt to re-do all its work from the beginning again.

Neither of these are "faults" of the OS/DB, but just inherient issues due to the fact that they can not predict the resource usage of their clientelle (ironic in that Oracle's name suggests that it should be capable of doing so however Smilie.)

Anyway, be greatful that your OS course is actually making you implement or play with these things in code. Theory means little without any hands on knowledge. In my opinion, too many schools teach theory without ever giving students practical work that makes use of it.
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Controlling processes knowing the PID's

Dear all, suppose that I start a process (named "father"). "father" starts in turns a process called "child" with an execv call (after a fork). In this way "father" will be notified if "chlid" crashes (SIGCHILD mechanism). The problem is: if "father" crashes, how can I do to be recreate a... (1 Reply)
Discussion started by: npalmentieri
1 Replies

2. UNIX for Dummies Questions & Answers

what are parent and child processes all about?

I don't follow what these are... this is what my text says... "When a process is started, a duplicate of that process is created. This new process is called the child and the process that created it is called the parent. The child process then replaces the copy for the code the parent... (1 Reply)
Discussion started by: xyyz
1 Replies

3. Shell Programming and Scripting

Parent/Child Processes

Hello. I have a global function name func1() that I am sourcing in from script A. I call the function from script B. Is there a way to find out which script called func1() dynamically so that the func1() can report it in the event there are errors? Thanks (2 Replies)
Discussion started by: yoi2hot4ya
2 Replies

4. Programming

fork() and child processes

Hello, How many child processes are actually created when running this code ? #include <signal.h> #include <stdio.h> int main () { int i ; setpgrp () ; for (i = 0; i < 10; i++) { if (fork () == 0) { if ( i & 1 ) setpgrp () ; printf ("Child id: %2d, group: %2d\n", getpid(),... (0 Replies)
Discussion started by: green_dot
0 Replies

5. Shell Programming and Scripting

fork() and child processes

Hello, How many child processes are actually created when running this code ? #include <signal.h> #include <stdio.h> int main () { int i ; setpgrp () ; for (i = 0; i < 10; i++) { if (fork () == 0) { if ( i & 1 ) setpgrp () ; printf ("Child id: %2d, group: %2d\n",... (1 Reply)
Discussion started by: green_dot
1 Replies

6. UNIX for Advanced & Expert Users

killing all child processes

Hi, Is there a way I can kill all the child processes of a process, given its process id. Many thanks in advance. J. (1 Reply)
Discussion started by: superuser84
1 Replies

7. Programming

Controlling a child's stdin/stdout (not working with scp)

All, Ok...so I know I *should* be able to control a process's stdin and stdout from the parent by creating pipes and then dup'ing them in the child. And, this works with all "normal" programs that I've tried. Unfortunately, I want to intercept the stdin/out of the scp application and it seems... (9 Replies)
Discussion started by: DreamWarrior
9 Replies

8. Windows & DOS: Issues & Discussions

Controlling AIX processes remotely using a NET app on a Windows server?

I have a .NET application that remotely starts, stops, and gets status of Windows services and scheduled tasks. I would like to add the capability of starting, stopping, and getting status of remote AIX applications also. Based on some preliminary research, one option may be to use 3rd party .NET... (0 Replies)
Discussion started by: auser1
0 Replies

9. Shell Programming and Scripting

Controlling the Number of Child processes

I am trying to implement the below using Ksh script on a Lx machine. There is a file(input_file) with 100K records. For each of these records, certain script(process_rec) needs to be called with the record as input. Sequential processing is time-consuming and parallel processing would eat up... (2 Replies)
Discussion started by: APT_3009
2 Replies

10. Shell Programming and Scripting

Get all child processes of a process

is there a universal way of getting the children of a particular process? i'm looking for a solution that works across different OSes...linux, aix, sunos, hpux. i did a search online and i kept finding answers that were specific to Linux..i.e. pstree. i want to be able to specify a process... (2 Replies)
Discussion started by: SkySmart
2 Replies
LOCKF(3)						   BSD Library Functions Manual 						  LOCKF(3)

NAME
lockf -- record locking on files LIBRARY
Standard C Library (libc, -lc) SYNOPSIS
#include <unistd.h> int lockf(int fd, int function, off_t size); DESCRIPTION
The lockf() function allows sections of a file to be locked with advisory-mode locks. Calls to lockf() from other processes which attempt to lock the locked file section will either return an error value or block until the section becomes unlocked. All the locks for a process are removed when the process terminates. The argument fd is an open file descriptor. The file descriptor must have been opened either for write-only (O_WRONLY) or read/write (O_RDWR) operation. The function argument is a control value which specifies the action to be taken. The permissible values for function are as follows: Function Description F_ULOCK unlock locked sections F_LOCK lock a section for exclusive use F_TLOCK test and lock a section for exclusive use F_TEST test a section for locks by other processes F_ULOCK removes locks from a section of the file; F_LOCK and F_TLOCK both lock a section of a file if the section is available; F_TEST detects if a lock by another process is present on the specified section. The size argument is the number of contiguous bytes to be locked or unlocked. The section to be locked or unlocked starts at the current offset in the file and extends forward for a positive size or backward for a negative size (the preceding bytes up to but not including the current offset). However, it is not permitted to lock a section that starts or extends before the beginning of the file. If size is 0, the section from the current offset through the largest possible file offset is locked (that is, from the current offset through the present or any future end-of-file). The sections locked with F_LOCK or F_TLOCK may, in whole or in part, contain or be contained by a previously locked section for the same process. When this occurs, or if adjacent locked sections would occur, the sections are combined into a single locked section. If the request would cause the number of locks to exceed a system-imposed limit, the request will fail. F_LOCK and F_TLOCK requests differ only by the action taken if the section is not available. F_LOCK blocks the calling process until the section is available. F_TLOCK makes the function fail if the section is already locked by another process. File locks are released on first close by the locking process of any file descriptor for the file. F_ULOCK requests release (wholly or in part) one or more locked sections controlled by the process. Locked sections will be unlocked start- ing at the current file offset through size bytes or to the end of file if size is 0. When all of a locked section is not released (that is, when the beginning or end of the area to be unlocked falls within a locked section), the remaining portions of that section are still locked by the process. Releasing the center portion of a locked section will cause the remaining locked beginning and end portions to become two separate locked sections. If the request would cause the number of locks in the system to exceed a system-imposed limit, the request will fail. An F_ULOCK request in which size is non-zero and the offset of the last byte of the requested section is the maximum value for an object of type off_t, when the process has an existing lock in which size is 0 and which includes the last byte of the requested section, will be treated as a request to unlock from the start of the requested section with a size equal to 0. Otherwise an F_ULOCK request will attempt to unlock only the requested section. A potential for deadlock occurs if a process controlling a locked region is put to sleep by attempting to lock the locked region of another process. This implementation detects that sleeping until a locked region is unlocked would cause a deadlock and fails with an EDEADLK error. The lockf(), fcntl(2), and flock(2) locks are compatible. Processes using different locking interfaces can cooperate over the same file safely. However, only one of such interfaces should be used within the same process. If a file is locked by a process through flock(2), any record within the file will be seen as locked from the viewpoint of another process using fcntl(2) or lockf(), and vice versa. Blocking on a section is interrupted by any signal. RETURN VALUES
The lockf() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. In the case of a failure, existing locks are not changed. ERRORS
The lockf() function will fail if: [EAGAIN] The argument function is F_TLOCK or F_TEST and the section is already locked by another process. [EBADF] The argument fd is not a valid open file descriptor. The argument function is F_LOCK or F_TLOCK, and fd is not a valid file descriptor open for writing. [EDEADLK] The argument function is F_LOCK and a deadlock is detected. [EINTR] The argument function is F_LOCK and lockf() was interrupted by the delivery of a signal. [EINVAL] The argument function is not one of F_ULOCK, F_LOCK, F_TLOCK or F_TEST. The argument fd refers to a file that does not support locking. [ENOLCK] The argument function is F_ULOCK, F_LOCK or F_TLOCK, and satisfying the lock or unlock request would result in the number of locked regions in the system exceeding a system-imposed limit. SEE ALSO
fcntl(2), flock(2) STANDARDS
The lockf() function conforms to X/Open Portability Guide Issue 4, Version 2 (``XPG4.2''). BSD
September 11, 2013 BSD
All times are GMT -4. The time now is 05:14 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy