[M3devel] refactoring threadwin32/threadpthread

[jay.krell at cornell.edu]

My ulterior motive here is to get you to maintain ThreadWin32  
indirectly and successfully.

  - Jay (phone)

On Nov 22, 2009, at 10:25 AM, Tony Hosking <hosking at cs.purdue.edu>  
wrote:

> 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/f91bb751/attachment-0002.html>