Sponsored Content
Operating Systems Solaris Application not working in multi core platform Post 302911795 by sreejesh on Sunday 3rd of August 2014 07:15:59 AM
Old 08-03-2014
Application not working in multi core platform

Hi,
I have a multiprocess C application (used POSIX library for threads and fork() & exec for creating process) of millions of LOC.

1. Which works fine in single processor machine.
2. Which works fine in multicore machine only if one core is enabled.

Problem is, which results an undefined behavior if more than one core/processor exists. Please suggest where/which area (APIs) may have issue?

Thank you
 

3 More Discussions You Might Find Interesting

1. Programming

Multi-platform includes?

I know that <cstudio> can also be <stdio> and can be written different ways on Linux then with windows. I've see some code doing a IFDEF __APPLE__ (I'm guessing, if compiled on a mac do whats between this) Is there one for Linux/Window? (3 Replies)
Discussion started by: james2432
3 Replies

2. UNIX for Advanced & Expert Users

Multi-platform Centralized Patch Management

We have a mix of AIX, HP-UX, Linux (RHEL and SLES), and Solaris in our environment. Currently we have seperate patch management systems for each platform (NIM, SD, Spacewalk, etc), but have started looking for a centralized patch management solution that would work for most, if not all, of our... (0 Replies)
Discussion started by: kknigga
0 Replies

3. Shell Programming and Scripting

Multi platform script perl or awk

Hi gurus, I am trying to match records in following format: (-,username,domain1.co.uk)\ (-,username,domain2.co.uk) either awk or perl must be used. I am using cygwin. I wrote following code which works and matches both above entries: awk 'BEGIN {musr="(-,username,+.co.uk)"} {if... (8 Replies)
Discussion started by: wakatana
8 Replies
pset_bind(2)							System Calls Manual						      pset_bind(2)

NAME
pset_bind() - bind process or thread to a processor set SYNOPSIS
DESCRIPTION
The function binds thread(s) or process(es) specified by idtype and id to the processor set pset. If idtype is then id specifies the pid of the process to be assigned, and the binding affects all threads of the process. If idtype is then id specifies the lwpid of the thread to be assigned, and the binding affects only the specified thread. You cannot spec- ify a pthread ID for pthreads in id, an lwpid is required. See in pthread_processor_bind_np(3T) for information on binding pthreads to processor sets. If idtype is then id specifies the effective user ID of all processes to be assigned, and the binding affects all threads in these pro- cesses. The operation is not a "success is all or none" type, because it rebinds as many processes as possible without error. If idtype is then id specifies the process group ID of all processes to be assigned, and the binding affects all threads in these pro- cesses. The operation is not a "success is all or none" type, because it rebinds as many processes as possible without error. All pro- cesses in a process group need not have same access permissions to target processor set. If opset is not it contains the previous processor set binding of the specified thread or process upon successful operation. However, opset is ignored if idtype is or All threads of a process need not be assigned to the same processor set. If id is then idtype identifies the target process(es) or thread(s) to be assigned to pset. The identifies the calling process, whereas identifies the calling thread. The identifies all processes with the effective user ID of the calling process, and identifies all pro- cesses in the process group of the calling process. If pset is or the system default processor set is the target processor set. If pset is the processor set binding is not changed, the current processor set's processor set ID is returned in opset. If idtype is or request has no meaning. No special access privileges are needed for operation. If pset is the same as the current processor set for the specified process or thread, the operation is considered a request. The system daemon processes are not restricted to any user defined processor sets. They may execute on any processor in the system irre- spective of the processor set configuration a user may have set up. The processor set binding of system daemon processes may not be changed. The operation on system daemon processes returns a special processor set ID of to indicate they are treated differently. Note: The system daemon processes are created in the kernel for kernel activities, and not the user daemon processes that execute in user space. A user with the privilege, or a user with EXEC permission for the processor set pset may affect the binding change. The and functions may be used to set and query the processor set access permissions. See pset_getattr(2)). If the thread or process being assigned to pset has binding to a processor or a locality domain in its current processor set, the binding is reassigned to a processor or locality domain in the new processor set pset. If pset is empty (no processors are assigned as yet), the behavior of function depends on the value of attribute. The default behavior on an attempt to bind a thread or a process to an empty processor set is to fail the request. The child process and its first thread created by a or function inherits the processor set binding from the parent process. The new threads in the multi-threaded process inherits their processor set binding from the creator thread. Security Restrictions Some or all of the actions associated with this system call require the privilege. Processes owned by the superuser have this privilege. Processes owned by other users may have this privilege, depending on system configuration. See privileges(5) for more information about privileged access on systems that support fine-grained privileges. RETURN VALUE
returns the following values: Successful completion. Failure. is set to indicate the error. ERRORS
sets to one of the following values if the corresponding condition occurs. The memory location pointed to by opset is not writable by the user. pset is not valid. idtype or id is not valid. pset is empty and the current setting of processor set attributes does not allow this operation on an empty processor set. The memory location pointed to by opset is NULL and the operation is requested. The processor set functionality is not supported by the underlying HP-UX version. User does not have necessary permissions to bind a thread or a process to specified processor set. The specified thread or process is a system daemon. The specified thread, process, user ID, or process group does not exist. EXAMPLES
Migrate the current thread to another processor set new_pset, and retrive its current processor set in old_pset. SEE ALSO
psrset(1M), fork(2), pset_assign(2), pset_create(2), pset_ctl(2), pset_destroy(2), pset_getattr(2), pset_setattr(2), vfork(2), privgrp(4), privileges(5). pset_bind(2)
All times are GMT -4. The time now is 11:40 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy