Xref: utzoo comp.lang.c++:9330 comp.sys.isis:391 comp.databases:6998 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!caen!ox.com!sendai!rich From: rich@sendai.sendai.ann-arbor.mi.us (K. Richard Magill) Newsgroups: comp.lang.c++,comp.sys.isis,comp.databases Subject: Re: Data sharing among lightweight tasks Message-ID: Date: 31 Aug 90 01:16:38 GMT References: <1990Aug30.164153.25008@swbatl.sbc.com> Sender: rich@sendai.UUCP Reply-To: rich@sendai.ann-arbor.mi.us Organization: Digital Works, Ltd. - Ann Arbor, MI Lines: 64 In-reply-to: cbs@swbatl.sbc.com's message of 30 Aug 90 16:41:53 GMT In article <1990Aug30.164153.25008@swbatl.sbc.com> cbs@swbatl.sbc.com (Brad Slaten 529-7636) writes: Our current application is using an object-oriented implementation under the ISIS lightweight tasking library and Unix. We have provided an interface to the Inter-process Communication (IPC) mechanism such that the application does not know when an object with which it is communicating requires IPC. The problem which occurs is that in making the IPC transparent, the lightweight task context switch is also transparent. The problem results from the fact that certain objects are shared among multiple tasks. When a context switch occurs from one task to another, any or all shared objects may be modified by a different task without the initial task having knowledge of this. Any and all thoughts (regardless of how wild) on this problem, or alternate approaches are welcome. Please send via e-mail. normal functional message handlers have the same problem with consistency except that the switch points are obvious. I've found that the conflicts you mention occur due to one of two causes. a) The two tasks occur in the same heavy weight process. When this is the case, I've usually architected something poorly. There should be an architecture that avoids using any form of locking by simply watching the start and end points of your exposure window and forcing IN THE CODE those events to be the same event in the eyes of the scheduler. I don't have a proof of this, but I could work on it if you like. b) There is a pre-emptive scheduler involved. For instance, the first task is in one heavy weight process and the second task is in a second heavy weight process running under the same kernel. In this case you need the support of that kernel to force the event window closed or to implement locks on the shared resource. The ISIS mechanisms are more general but solve this devolved case as well as they solve... c) The two tasks are really running asyncronously. For example, two heavy weight processes on a symmetric multiprocessor (the vendor usually provides a kernel level coordination mechanism), or two tasks running under different kernels. For this you really NEED something like ISIS. To be fair, I should also say that ISIS provides much more than this form of coordination and that the kernel level controls usually get in the way of some of ISIS's other guarantees. Off the cuff, I'd guess that your problem falls into category a. That is, if you've wrapped the isis calls in an isis object, but your other objects are capable of deadlock, then I think you've failed to completely wrap isis. You need some way for the isis object to prevent the deadlocks. I don't mean locks here, I feel there should be a better message interface or delivery algorithm that allows the isis object to close the event window. If for some reason the isis object or it's interface can't be changed, you might try writing a queue object and attaching it or subclassing from it. On receiving a message, queue it. If the queue was empty, then invoke the message handler for that object. If the queue was not empty, simply return. The handler then handles messages from the queue sequentially until the queue is empty. This is essentially the same mechanism that isis uses between heavy weight processes. If you're isis object insists on hiding it from you, then you'll probably end up reinventing it or using locks. Of course, if you use isis locks that are wrapped in your isis object, you'll just end up with another recursion on the deadlock. Perhaps unwrapping the isis calls would be simpler?