From: David W. <wa...@cs...> - 2005-07-21 17:39:22
|
Terrance Swift writes: > . Anyway, give me until the end of the week to come up with a > radically revised proposal. There are a lot of strong reasons for making > thread-shared tables the default, and I'd like to convince David > (pushover) Bart (moderate) and Michael (hard). So maybe I'll be a pushover, but let me give you some of my thinking on the issue. My concerns at the moment are very practical. I want to begin to migrate the classifier to a multithreaded environment. This is mostly an exercise for now, but we will probably want to do this as our first serious application of XSBMT, I think. So my approach will be to start by writing a main driver loop and start up a couple of threads to each handle a classification problem. Now what do I have to do? The semantics of tables and asserts is now different in the multithreaded system, since they are now global. So I have now to go through all the dynamic and tabled predicates and see whether they should be local or global. For example for dynamic predicates, I have to check if they have retracts to them and if they do, I either have to declare them local, or figure out how to get rid of the retracts or otherwise re-implement it. If the table has an abolish, I have to see whether its use is consistent with the new global abolish semantics. OK, so let's start with the dynamic predicates, which I do use to store stuff in the classifier. (I know, it ought to be pure, and I do my best, but....) I just ran the classifier and loaded a large KB, and then printed out all the dynamic predicates (using predicate_property(??,dynamic).) I am embarassed to tell you how many dynamic predicates there are. But I will. There are 135 in usermod and 222 overall. (40 are cdf-related.) Actually a number of them are within the XSB system (e.g. _$index and _$op) and they will have to be sorted out in any case. OK, so that's a lot of stuff to work through before I can try to test it out. And while I was at it I did the same to find out about tabled predicates used in the classifier, and there are 78 tabled predicates. So I have to try to rationalize those, too. Now how would I proceed if we were able to maintain the current semantics for dynamic and tabled predicates within a thread as the default. In this case I could get a running system in no time (ha ha), just by having threads run completely on their own with no sharing. Then I would look to see where I could share predicates easily and declare them shared. So I would have a multithreaded application that would start out working, maybe inefficiently, and would continue working as I worked on it. Now, of course this really is just a methodology that is (mostly) independent of the default. If the default is global, then all I'd have to do is go find all those 222 dynamic declarations (oh yeah, but I'll bet not ALL of those are explicitly declared dynamic....) and change them to "local_dynamic" declarations, and similarly for the table declarations. And then I use the same methodology changing the local_dynamic back to dynamic (i.e. global_dynamic). But I do think it would be quite a bit easier to have the default be the semantics that is consistent with the old semantics. So that's why I support the "local" default for dynamic and tabled predicates. -David |