These seem like some of the same issues I'm seeing with my simple multi-core app: now that I start separate, independent jobs to do the work, it's more complicated to time the task than when it was single-threaded within the main session. My quick-and-dirty solution was to have each task log its start, finish and elapsed times to a common file but this raises the issues you're talking about here: how do I know when I'm done from the point of view of the dispatcher? Also, I may now have a rare, output file contention bug just waiting to bite me.
On Wed, Mar 17, 2010 at 10:31 AM, Don Guinn <[email protected]> wrote: > I didn't want to get into the more sticky issues as I just wanted to get > across the idea of being able to schedule work and wait on it without > having > to let J go to idle. As to handling your concerns, wait could have an > optional count of semaphores to be set before it ends. Then looking at > which > semaphores are set tells which statements have completed. > > What got me thinking along this line was when I saw the first cut of J7. > When jfe handles input and output, J is idle. Or is it? All kinds of > possibilities are opened up when I can write J statements that execute when > J thinks it is idle. And that brings up a number of questions in my mind > with J7. If I have an error in the jfe code, where does it go? What does > the > 13!:1'' output look like? If I signal a break, where does it go? How can I > use sockets if jfe uses sockets? But now I'm rambling. > > On Wed, Mar 17, 2010 at 7:32 AM, Robert Bernecky <[email protected] > > > wrote: > > > I've been contemplating introducing something similar into the APEX > > compiler: basically, it's a variant on the rank conjunction. > > Effectively, we have what might be considered an array of gerunds, > > which we apply, rank-like, to some data. > > > > The difference is that, unlike rank, we don't wait until all the > > execution threads complete, and then laminate the results. > > Instead, execution terminates when ANY thread completes, and > > that becomes the result. At least, that's the rough idea. > > > > There are, as usual, some rough edges: > > > > a. What if more than one thread completes at the same time, as > > might happen if we were, say, waiting for several sockets > > to change state, or if multiple chessboard evaluations completed > > at once? > > > > b. How do we identify which thread(s) completed? One way, of course, > > would be to append, either tacitly or explicitly, the thread's > > index/indices into the argument array. > > > > > > Bob > > > > Don Guinn wrote: > > > >> . . . > >> > >> > >> I would like to write something like: > >> > >> rotatepicture=:3 : 0 > >> '(rotate fread y)fwrite y' startcore y > >> ) > >> > >> events=:rotatepicture each {."1 fdir '*.jpg' > >> wait events > >> > >> where startcore schedules the statement to be run and returns a > semaphore > >> that is set when the statement completes. Then wait hangs until all the > >> semaphores are set. Can't do that in J. Or can we? > >> > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
