Thanks for time. I did not think of using mmap. (Rather I'm bit unsure about what to use when - so I statyed with shmat).
Yes, I when I gave address instead of (void*)0 with shmat, it attached to same address. What would you prefer? - mmap with address or shmat with adress? - or both are same? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 04 April 2007 17:39 To: Borse, Ganesh Cc: 'perf-discuss@opensolaris.org' Subject: Re: [perf-discuss] Request for guidance on shmat() call attaching at different addre ss Hi Ganesh, I have done the same kind of thing you are trying to do with shmget/shmat, but I used mmap. With mmap, I needed to specify the address (first arg to mmap(2)) with the MAP_FIXED flag. Have you tried specifying an address instead of the "(void*)0"? (I admit, using SHM_SHARE_MMU flag seems like it would end up giving the same address, but that is only an assumption). max Borse, Ganesh wrote: > No, it is not the address (the 2nd param) passed to shmat calls. I'm passing > "(void*)0". > It is the address returned by shmat, after attaching the segment. > > My code is as below:- > int id = shmget(key,size,(0777 | IPC_CREAT | IPC_EXCL)); if(errno == > EEXIST){ > id = shmget(key,size,(0777 | IPC_CREAT)); } > > suht->_dataMemSegments[idx]._dataMemory = (pSUHT_ITEM)shmat(id, (void > suht->*)0, 0777 | SHM_SHARE_MMU); > if(NULL == suht->_dataMemSegments[idx]._dataMemory || errno != 0){ > printf("shm:_dataMemory:failed: errno:%d\n",errno); > return errno; > } > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 04 April 2007 16:49 > To: Borse, Ganesh > Cc: 'perf-discuss@opensolaris.org' > Subject: Re: [perf-discuss] Request for guidance on shmat() call > attaching at different addre ss > > Hi Genesh, > Are you specifying an address in your shmat calls? Can you post code > segments doing shmget/shmat? > > max > > Borse, Ganesh wrote: > >> Hi, >> I am facing a problem of shared memory segment getting attached at >> different address, when the processes using it go down and attach >> count goes to zero. >> >> This causes the problem when the processes next time come up & try to >> access the addresses taken from the shared memory segment. >> >> The scenario in brief:- >> I've 3 processes using multiple shared memory segments. Shared memory >> segments (shm) are also used in hierarchical fashion. >> >> One shm is used as a high level data structure to hold pointers to >> other shms. >> Second shm is an array of pointers to structures (data blocks) which >> will get allocated in the third shm. For the other 2 processes to >> access these blocks, their addresses will be stored in this second >> shm (an array). >> >> The third shm actually holds the data as retrieved by the server >> process from database. This is acting as cache. >> When the third shm gets completely used, the server process creates >> new shm and starts storing data into it. Once all data gets stored, >> server process goes down - without removing any shm. >> >> Next when the client processes comes up, they attach to all these >> shms created by server process. >> When the client process calls "shmat" on the first 3 memory segments, >> shmat returns the same address which it returned to server process >> (these addresses are stored in 1st shm). >> >> But, when client process tries to attach to 4th segment (which was >> created after the third data shm filled up), the shmat returns >> totally different address than that of returned to the server process. >> >> Since, the addresses stored in array shm correspond to the different >> shm address, when the client process tries to access those addresses, >> it crashes with SIGSEGV. >> >> I am using SHM_SHARE_MMU flag with shmat to use the feature of ISM & >> to get same address. >> >> Any clue/ hint why only the 4th (last segment) shmat returns >> different address? Is this the normal behavior? >> Could I be doing something wrong only while creating this segment? >> >> Please help. >> >> Thanks and Regards, >> GaneshB >> >> ===================================================================== >> = ======== Please access the attached hyperlink for an important >> electronic communications disclaimer: >> >> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html >> ===================================================================== >> = >> ======== >> >> --------------------------------------------------------------------- >> - >> -- >> >> _______________________________________________ >> perf-discuss mailing list >> perf-discuss@opensolaris.org >> > > > ====================================================================== > ======== Please access the attached hyperlink for an important > electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ====================================================================== > ======== > > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
