[Python.NET] About use DotNet threading lib

Jeffrey Bush jeff at coderforlife.com
Wed Mar 4 19:34:26 CET 2015


You seem to be slightly misinformed about the cPython GIL. While it is true
that it prevents two Python statements from being interpreted at the same
time, many "long-running" functions automatically release the GIL while
they are being executed. For example, when reading and writing a file the
GIL is released, allowing other threads to do things at that time. Many
other built in functions also release the GIL: time.sleep(),
select.select(), lock.acquire() and in general anything else that can
block. Also, the ctypes library releases the GIL in when calling native
functions (except when using ctypes.PyDLL). Many third party libraries also
do this as well (for example, numpy/scipy does this all the time). I have
written plenty of multi-threaded Python programs that make full use of all
the cores on a machine - maxing them all out.

If your code is really heavy on the Python statements that cannot be
executed at the same time one solution may be to spawn multiple Python
interpreters so that they can execute statements at the same time. The
downside is that it is more difficult to share data between "threads". See
https://docs.python.org/2/library/multiprocessing.html which handles a lot
of this for you and is designed to be a replacement for threads.

Now on to your question. If you start a .NET thread it will not be under
the influence of the Python GIL since it is running .NET code and not
Python. The .NET code knows nothing about the GIL and Python has no ability
to control the execution of individual .NET statements (which don't exist
once compiled anyways). However, if your .NET code runs a Python statement,
those statements will be subject to the GIL.

So the basic idea is that no two Python statements may be interpreted at
the same time using the same interpreter, regardless of where they came
from, under cPython. However multiple Python statements may be executed at
the same time (if at least one is designed to release the GIL). And any
non-Python code may be run at the same time without influencing or being
influencing the GIL.

Just for an explanation of why the GIL exists in the first place: many of
the built-in classes (e.g. dict) are not thread-safe on their own and if
used without the GIL in a multi-thread way would cause lots of problems.
Other languages address this in other ways, e.g. .NET has Dictionary vs
ConcurrentDictionary. In Python they addressed it by making the default
situation that all statements are thread-safe instead of using explicitly a
different class. There are some other reasons why it exists as well, but
this is getting long.

Jeff

On Tue, Mar 3, 2015 at 10:11 PM, Longhui Xiong <xionglonghui at gmail.com>
wrote:

> Hi there,
>
> I am using python for DotNet, I have to say, it is great.
>
> As we know, cpython has the Global Interpreter Lock (GIL) on
> multi-threading. So it can not use multi-core.
>
> So I have one question, if I import CLR and use System.Threading on python
> for .net, but don't use cpython threading,
>
> My question: Does it still has GIL on multi-threading if I use DotNet
> threading lib? Can it use multi-core use DotNet threading lib.
>
> I know IronPython has no GIL and multi-threaded code can use multi core
> processors. So I pay attention this issue, on python for dotnet, if I use
> DotNet threading lib instead of cPython threading lib, Can multi-threaded
> code use multi core,  it still has GIL?
>
> I look forward to your reply.
>
> Regards
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> https://mail.python.org/mailman/listinfo/pythondotnet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythondotnet/attachments/20150304/e539fabd/attachment.html>


More information about the PythonDotNet mailing list