juh@qt.IPA.FhG.de (Juergen Henke) (03/27/91)
Our news server broke down last week - this is a second try. On several *ixes i can supply the shmat-call with a address, at which i want to access the shared memory. This works apparently also on a 9000/375 with HP-UX 7.0. The man page on the 825 claims however, that this is not possible on this machine... So, PLEASE, why ? And is there a workaround for this ? Many, many, thanks in advance, Juergen -- _________________________________________________________________________ Juergen Henke, e-mail juh@qt.IPA.FhG.de, PSI-mail PSI%4571109306::JUH_IPA Fraunhofer-Institut f. Produktionstechnik u. Automatisierung Eierstrasse 46, D-7000 Stuttgart 1
stroyan@hpfcso.FC.HP.COM (Mike Stroyan) (03/28/91)
>On several *ixes i can supply the shmat-call with a address, at which i >want to access the shared memory. This works apparently also on a 9000/375 >with HP-UX 7.0. >The man page on the 825 claims however, that this is not possible on this >machine... > >So, PLEASE, why ? And is there a workaround for this ? The 800 series caches data by its virtual address rather than it's physical address. This means that all processes must agree on the virtual addresses of shared memory segments so that the memory locations will end up in the same cache entries for all processes. These forced addresses are the same from one process to the next. They are also allocated on a system basis, so that you will never have address collisions when attempting to map segments. Mike Stroyan, mike_stroyan@fc.hp.com
decot@hpisod2.cup.hp.com (Dave Decot) (03/28/91)
> On several *ixes i can supply the shmat-call with a address, at which i > want to access the shared memory. This works apparently also on a 9000/375 > with HP-UX 7.0. > The man page on the 825 claims however, that this is not possible on this > machine... The man page is correct. > So, PLEASE, why ? And is there a workaround for this ? It has to do with the s800 memory architecture. Virtual addresses in user processes are unique across the whole system. In fact, it is possible to determine from a given virtual address which process it belongs to. If the s800 permitted user-supplied addresses to be added to the address space of the current process, this would violate that arrangement. The workaround depends, as always, on what you are trying to do. Since a shared memory segment will always be attached at a different address in different processes, addresses in one process are not directly usable in another process. If you want to share data structures between processes via shared memory, you can encode any addresses in the data structure as offsets from the beginning of the shared memory segment, and add the beginning address in each process to the offset to locate the data in that process. > Many, many, thanks in advance, You're welcome. Dave Decot, HP DISCLAIMER: The text above is provided for infomational purposes only; it is the author's opinion and not necessarily that of Hewlett-Packard Company.
jonb@hpcupt1.cup.hp.com (Jon Bayh) (03/30/91)
There are two responses to this string, one from Mike Stroyan and one from Dave Decot. Mike's is correct in every detail; Dave's is not entirely right. All SHARED items in the S[78]00 system use the same virtual address, both space ID and offset, and use protection IDs to prevent unauthorized access to the virtual address space. This includes shared text, shared memory, and (in 8.0) shared libraries. For user stack, user data, and kernel stack, the virtual addresses are different for each process. Often this is accomplished by using a different space ID for each process, but retaining the same offset. As Mike said, the reason this mapping is used is because a virtual cache is used, rather than a physical cache. The primary reason that a virtual cache is used is to provide faster access to the cache--- both the cache lookup and the virtual translation can go on in parallel. Since the virtual address mapping is always at a fixed address for all processes that access a given shared memory segment, you can use pointers into the virtual segment without worrying about addr+offset computations. That's in stark contrast to a machine that allows you to assign the segment to an arbitrary address; in that case, all programs using the shared memory would have to agree on an attach point if they want to share pointers to data. The one thing you do have to watch out for with the HPPA mapping, is that each time the shared memory segment is created (as opposed to being attached), a different address may be used than was used the last time. So you can't, for instance, run a program, save the data and pointers to a file, restart the program, attach a new shared memory segment, and use the old data and pointers. Addr+offset based programs are always more portable, even though they may be slower. Jon Bayh jonb@hpda.cup.hp.com
decot@hpisod2.cup.hp.com (Dave Decot) (04/02/91)
Thanks for the corrections and clarifications. Dave