[M3devel] refactoring threadwin32/threadpthread

[Tony Hosking]

It *might* be possible to achieve something like this, though we should probably implement it as a simple adaptation layer above the thread implementations.  This could be useful for some directions I was hoping to take the threads subsystem in order to speed up mutex and CV implementations based on use of wait-free synchronization in the common case.  Ultimately, it means we would not even need an underlying CV implementation.  All we need are mutexes, and then only in the case that threads contend. 

Before we do that though, I'd like at least to prototype it with pthreads, so I think it would be a good idea for now simply to let the dust settle.  It is more important that we get the new CM3 release out the door.

On 22 Nov 2009, at 00:52, Jay K wrote:

> Tony, it seems to me that ThreadWin32.m3 / ThreadPThread.m3 can be largely combined into common code.
>  
> If you come up with common names for
>  EnterCriticalSection vs. pthread_mutex_lock => SysLock?
>  LeaveCriticalSection vs. pthread_mutex_unlock => SysUnlock?
>  TlsGetValue vs. pthread_getspecific => PerThreadGet?
>  TlsAlloc vs. pthread_key_create => PerThreadAlloc?
>  etc.
>  
> Then you can make a bunch of the code identical.
>  
> I realize there is a more serious diversion wrt condition variables not being supported (unless
> we drop pre-Vista support, which I'm not inclined to).
>  
> ThreadSuspend/Resume I think is already somewhat abstracted,
> due to how Darwin/FreeBSD are written.
> The Win32 names are pretty good in many places imho.
>  
> There may even be commonality with ThreadPosix.m3.
>  
>  
> You know, we have:
> ThreadPosix.m3 1400 lines
> ThreadPThread.m3 1400 lines
> ThreadWin32.m3 1000 lines
>  
> surely we don't need that much.
>  
>  
>  - Jay
> 
> 
> 
> 
> 
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091122/332a6f05/attachment-0002.html>