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. > DS > _______________________________________________ > 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
