hello!

About the lisp mutex implementation. I am just cross checking, is this the related
definition?
=============================

    typedef struct {
      XRECORD_HEADER
      gcv_object_t xmu_name _attribute_aligned_object_; /* name */
      gcv_object_t xmu_owner _attribute_aligned_object_; /* owner (thread) */
      uintL xmu_flags; /* mutex flags - recursive? (by default - no)*/
      uintL xmu_recurse_count; /* how many times we have obtained the mutex */
      /* following is pointer to malloc()-ed memory. it's location should not
         change across GC since we may wait on it while GC is working.
         another option is to pin the mutex record but this leads to heap
         fragmentation and there should not be so many many mutex objects
         anyway */
      xmutex_t *xmu_system;                              /* OS object */
    } * Mutex;
    #define mutex_length  2
    #define mutex_xlength (sizeof(*(Mutex)0)-offsetofa(record_,recdata)-mutex_length*sizeof(gcv_object_t))

    #define mutex_flag_recursive  0x0001
    #define mutex_recursivep(obj) (TheMutex(obj)->xmu_flags & mutex_flag_recursive)

=============================

FYI I downloaded the lispbibl.d file from here
(http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/lispbibl.d)
and I don't know why but the code there is not up to date with the lispbibl.d
from mercurial repo.


>> 5.  In [xthread.d, line 99,152] what does #define THREADPROC_SIGNATURE do?
> This is just a syntax sugar to hide win32/posix thread function return type.
Can you elaborate more?


> Recent win32 versions (not sure from when exactly) have real
> condition variables
> (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682052(v=vs.85).aspx).
> The reason we do not use them is that we want to support windows
> xp as  well. Of course some ifdefs are possible but nobody bothered
> yet.

Thanks. Yes! I did find that condition variables are now part of win32
api since windows Vista. Wouldn't it be good to add the additional
usage of native condition variables now that they are supported?
It might increase the performance. Should I read the proper docs and
code another macro with new condition variables?


I tried to reproduce bugs tagged with 'multithreading' over at sourceforge.
But haven't been successful (obviously due to lack of knowledge)

Anyway I am going through the zthread.d file, understanding every part
of it. And alsofamiliarizing with the internals which should be completed
by this Monday.

Also, in a previous email you wrote
> xthread.d should be extended with CAS(I suggest to extend testandset macros).
what more should I read to get started with it?

So what should I do next?
I still haven't had a grasp of lisp mutex. I would be clear with its usage and
understanding after I have finished zthread.d, right?



On Thu, May 1, 2014 at 11:18 PM, Vladimir Tzankov <vtzankov@gmail.com> wrote:
> 1.  Is test-and-set faster than compare-and-swap?
testandset in xthread.d is special case of cas with 0/1 values.


> 2.  In [xthread.d, line 104 ]  its mentioned "raw mutex used for thread
> suspension/resume". What does a raw mutex refer to here? Is it any
> different from a normal mutex? Does by raw mutex you mean .. simply
> a mutex (! mutex/condition variable pair) ?

In all comments "raw" mutex means operating system mutex while "mutex"
means lisp object mutex (see lispbibl.d:6831).
"raw" mutex is used for lisp mutex implementation.

> 3.  I came across futex. It's a kernel facility the enables fast
> implementations
> of mutex in userspace and is used to implement basic locking. Why don't we
> incorporate it in achieving locking ? since Pthread Mutex in the latest
> Linux
> distributions are implemented through Futex logic.

futex is linux only thing. clisp runs on bsd, win32, etc. Also futex
cannot be used with condition variables.

> 4.  In [xthread.d, line 52 ] I could not understand the 'Create a new
> thread'
> method's  void* (*startroutine)(void*) argument. Please, also provide me
> with a definition of startroutine.

See zthread.d:228
This is start routine for all threads created from lisp code.

> 5.  In [xthread.d, line 99,152] what does #define THREADPROC_SIGNATURE do?
This is just a syntax sugar to hide win32/posix thread function return type.

> 6.  In [xthread.d, line 156],  its mentioned 'an inefficient implementation
> of
> condition variable for win32.'. Why don't we use windows 'Events' instead of
> a condition variable, since I read they are like a mutex/condition pair
> wrapped
> around a boolean.
> plus there's also a to-do marked there-  "TODO : make it better."

Condition variable emulation on win32 is not exactly inefficient but
is not fair for sure. Win32 event is very different compared to posix
condition variables - please go over related docs again.
Recent win32 versions (not sure from when exactly) have real condition
variables (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682052(v=vs.85).aspx).
The reason we do not use them is that we want to support windows xp as
well. Of course some ifdefs are possible but nobody bothered yet.