|
Boost : |
From: terekhov (terekhov_at_[hidden])
Date: 2002-01-25 05:14:37
--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> > [...]
> > > > May I just repost
> > > > the last message I've sent to you yesterday (you did not
reply
> > > > yet)?
> > >
> > > Feel free to. I haven't replied because there wasn't much new
> that
> > I
> > > felt required replies, and I'm hip deep in other things :).
> >
> > To: "William Kempf" <williamkempf_at_h...>
> > cc: bdawes_at_a..., pdimov_at_m...
> > From: Alexander Terekhov/Germany/IBM_at_IBMDE
> > Subject: Re: Boost.Thread/thread_ptr ?!
>
> [snip]
>
> Like I said before, I don't see too much that needs an immediate
> reply, though I'm looking forward to hearing other voices on this.
> However, I'd like to ask an important question: is there anything
in
> the redesign I've posted that makes building your thread_ptr design
> on top of it either difficult or impossible? The answer to this, I
> think, will help to illuminate problems in the direction I'm
leaning
> towards now, as well as to decide whether or not either of us is
> totally off base here.
The answer would be definitely:
"no, there's nothing in the posted design that makes things
difficult or impossible to use it as the basis for implementing
my design"
*IF* the posted design would fully support (and be
compatible wrt C-level cancel/exit/etc functions in
my OLD code) the full functionality (*100%*) of the
following *mandatory* (not optional) POSIX threading
calls (thread/mutex/cond attributes aside for now,
these are just pthread_* calls used in the current
version of mythread.c):
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_unlock
pthread_mutex_destroy
pthread_cond_init
pthread_cond_wait
pthread_cond_signal
pthread_cond_broadcast
pthread_cond_destroy***
pthread_key_create
pthread_key_delete
pthread_setspecific
pthread_getspecific
pthread_create
pthread_detach
pthread_join
pthread_self
pthread_exit
pthread_once
pthread_cleanup_push
pthread_cleanup_pop
pthread_cancel
pthread_setcancelstate
pthread_setcanceltype
regards,
alexander.
[***] BTW, the last time I've looked at it,
WIN32 version was lacking proper sync. in
boost::condition's destructor.
P.S. Perhaps you already know it, but
apropos your recent "standardization",
POSIX++ vs WIN32, lowest common denominator,
etc discussions, I just would like to
briefly mention that MS-WIN threading++
MODEL/API is now THE ECMA-*STANDARD*:
(doc.list w/o Mutex/Auto-/Manual-events,etc stuff)
Directory of G:\C#\tr-084\2001tc39-020b\System\Threading
10/02/2001 12:44p 546,816 Interlocked.doc
11/14/2001 05:38p 40,519 Interlocked.pdf
10/02/2001 12:44p 568,832 Monitor.doc
11/14/2001 05:36p 56,873 Monitor.pdf
10/02/2001 12:44p 30,208
SynchronizationLockException.doc
11/14/2001 05:36p 20,093
SynchronizationLockException.pdf
10/02/2001 12:44p 686,080 Thread.doc
11/14/2001 05:36p 138,010 Thread.pdf
10/02/2001 12:45p 26,624 ThreadAbortException.doc
11/14/2001 05:36p 17,664 ThreadAbortException.pdf
10/02/2001 12:44p 26,624 ThreadPriority.doc
11/14/2001 05:36p 18,577 ThreadPriority.pdf
10/02/2001 12:45p 21,504 ThreadStart.doc
11/14/2001 05:37p 13,391 ThreadStart.pdf
10/02/2001 12:44p 34,816 ThreadState.doc
11/14/2001 05:37p 23,926 ThreadState.pdf
10/02/2001 12:45p 32,256 ThreadStateException.doc
11/14/2001 05:37p 21,215 ThreadStateException.pdf
10/02/2001 12:45p 22,016 Timeout.doc
11/14/2001 05:37p 14,015 Timeout.pdf
10/02/2001 12:45p 546,816 Timer.doc
11/14/2001 05:37p 41,480 Timer.pdf
10/02/2001 12:45p 23,552 TimerCallback.doc
11/14/2001 05:37p 14,747 TimerCallback.pdf
10/02/2001 12:43p 530,944 WaitHandle.doc
11/14/2001 05:35p 30,514 WaitHandle.pdf
26 File(s) 3,548,112 bytes
more info:
http://www.cs.umd.edu/~pugh/java/memoryModel/archive/0938.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk