On 14 April 2011 20:58, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> wrote: > On 04/14/2011 08:42 PM, mark florisson wrote: >> >> On 14 April 2011 20:29, Dag Sverre Seljebotn<d.s.seljeb...@astro.uio.no> >> wrote: >>> >>> On 04/13/2011 11:13 PM, mark florisson wrote: >>>> >>>> Although there is omp_get_max_threads(): >>>> >>>> "The omp_get_max_threads routine returns an upper bound on the number >>>> of threads that could be used to form a new team if a parallel region >>>> without a num_threads clause were encountered after execution returns >>>> from this routine." >>>> >>>> So we could have threadsvailable() evaluate to that if encountered >>>> outside a parallel region. Inside, it would evaluate to >>>> omp_get_num_threads(). At worst, people would over-allocate a bit. >>> >>> Well, over-allocating could well mean 1 GB, which could well mean getting >>> an >>> unecesarry MemoryError (or, like in my case, if I'm not careful to set >>> ulimit, getting a SIGKILL sent to you 2 minutes after the fact by the >>> cluster patrol process...) >>> >>> But even ignoring this, we also have to plan for people misusing the >>> feature. If we put it in there, somebody somewhere *will* write code like >>> this: >>> >>> nthreads = threadsavailable() >>> with parallel: >>> for i in prange(nthreads): >>> for j in range(100*i, 100*(i+1)): [...] >>> >>> (Yes, they shouldn't. Yes, they will.) >>> >>> Combined with a race condition that will only very seldomly trigger, this >>> starts to sound like a very bad idea indeed. >>> >>> So I agree with you that we should just leave it for now, and do >>> single/barrier later. >> >> omp_get_max_threads() doesn't have a race, as it returns the upper >> bound. So e.g. if between your call and your parallel section less >> OpenMP threads become available, then you might get less threads, but >> never more. > > Oh, now I'm following you. > > Well, my argument was that I think erroring in that direction is pretty bad > as well. > > Also, even if we're not making it available in cython.parallel, we're not > stopping people from calling omp_get_max_threads directly themselves, which > should be OK for the people who know enough to do this safely...
True, but it wouldn't be as easy to wrap in a #ifdef _OPENMP. In any event, we could just put a warning in the docs stating that using threadsavailable outside parallel sections returns an upper bound on the actual number of threads in a subsequent parallel section. > Dag Sverre > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
