Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!usc!bloom-beacon!mcgill-vision!topper From: topper@mcgill-vision.UUCP (Anthony Topper) Newsgroups: comp.realtime Subject: Re: Shared memory with multiple processors running VxWorks (long) Keywords: VxWorks/multiple processors/ shared memory Message-ID: <1644@mcgill-vision.UUCP> Date: 16 Sep 89 16:24:52 GMT References: <4252@ncar.ucar.edu> Reply-To: topper@Moe.McRCIM.McGill.EDU.UUCP (Anthony Topper) Organization: McGill University, Montreal Lines: 99 >Has anyone else written code (that you would be willing to share) to provide >these facilities? Do other real-time operating system vendors offer >better multi-processor support? It seems that a number of vendors are weak in this area. VxWorks is no exception. We had an application that required very fast interprocessor communication and vxWorks didn't have it so I wrote one. However our application required such raw speed that the package I created was not used, but I believe would fit many people's needs. Some features (long): o interprocessor, interprocess communication on the same backplane. o Very fast. It fits in between vxWorks pipes and sockets. Half the speed of pipes but 50-100 times faster than sockets. o uses vxWorks file level to be as seemless as possible. The same user code can be used for sockets between vxWorks "boxes", my shared mem for same backplane, and vxWorks pipes within a CPU. So you choose what is most appropriate. o Has many modes of operation: queue, ring buffer, mailbox, plain buffer. Each of these can be blocking or non-blocking and the blocking mode can use interrupt demons to wake processes or use "test-and-set" loops. (the former uses mailbox or backplane interrupts to wakeup processes on other cpus and requires interrupt processing, the latter takes up bus bandwidth but no interrupt overhead). All of these modes are available for each block of memory requested by the user, so the appropriate mode can be used where needed. o Supports memory in contiguous or non-contiguous blocks any where on VME or VSB bus. o Does auto-synchronization on boot-up and simultaneous memory allocation. o Has semaphore mode for counting semaphores (minimizes allocation of memory). o Uses about 2.2k memory per memory partition requested for overhead. Base overhead is about 32k. All in shared memory. Requires about 30K of code memory on CPU board. o can configure for cold-boot wipe contents of memory or not. o performance: 1 byte 64 bytes 255 bytes ------ -------- --------- VxWorks pipe: 360 390 490 shMem tas: 700 780 1150 shMem demon: 1700 1700 2800 sockets (TCP/IP): 200000 200000 200000 (datagrams are faster) All times in microseconds. This test using vxWorks timer functions between two Heurikon-V2F's (Mc68020 @ 20Mhz, 0 wait) and using Micro-Memory's MM6300 shared memory board (200 ns access, I think) o for example user does something like: CPU producer: fd = open("/dev/sharedMem/VME/myBlock", "SIZE=1000, ELSIZE=10, QUEUE, BLOCK"); for (i = 1; i < however_many; i++); { do some processing get some data ... write(fd, buffer, 10); } CPU consumer: fd = open("/dev/sharedMem/VME/myBlock", "SIZE=1000, ELSIZE=10, QUEUE, BLOCK"); for (i = 1; i < however_many; i++); { read(fd, buffer, 10); do some processing with the data ... } The open requests are automatically synchronized, the rest follows naturally. o Current implementation Only runs on the vw3.2 and Heurikon V2F cpus. A port to vw4.x and generic vxWorks CPUs is quite straight forward to do, though supported CPUs would require mailbox interrupts. I started to do it, but I just don't have the time. The code is about a year old and I haven't looked at it in quite some time. I did have a neat demo of five cpus doing a classic consumer/producer problem. o I also did a port of curses and unix level 3 file I/O for vw3.2 which is now obsolete. o I people want it they can send me a tape and I'll copy for you. I'll be away all october so be patient. Are you listening Wind River? I'll do a no cash deal for the rights if you are interested. Tony Topper _________________ McGill University, EE Dept. | / \ / \ / \ | Montreal, Canada \/ \/ \/ \/ \ *** *** / smart mailers: topper@mcgill-vision.uucp \ *** *** / usa: {ihnp4,decvax,akgua,utzoo,etc}!utscri \ * *** * / !musocs!mcgill-vision!topper \ *** / or \ * / think!mosart!mcgill-vision!topper \ / ARPAnet: topper@larry.mcrcim.mcgill.edu \ / bitnet: mcgill-vision!topper@musocs.bitnet Bell Canada: (514) 398-3788