Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #901 > unrolled thread

Re: The threading specs in the standard: a new catastrophe

Back to article view | Back to comp.unix.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: The threading specs in the standard: a new catastrophe jameskuyper <jameskuyper@gmail.com> - 2011-07-07 15:25 -0700
    Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-07 16:12 -0700
      Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-07 22:41 -0400
      Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-08 12:47 -0700
        Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-08 13:11 -0700
          Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-08 16:56 -0700
          Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-09 23:55 +0200
            Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-09 18:40 -0700
    Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-08 01:16 +0200
      some sane words, for sure "Greg A. Woods" <woods@robohack.org> - 2011-07-07 18:33 -0700
      Re: The threading specs in the standard: a new catastrophe jameskuyper <jameskuyper@gmail.com> - 2011-07-08 08:34 -0700
        Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-08 10:47 -0700
          Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-09 06:57 -0400
            Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-09 13:59 +0200
              Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-09 14:45 +0200
              Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-10 15:47 -0700
                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-11 13:38 +0200
              Re: The threading specs in the standard: a new catastrophe Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-11 16:12 +0300

#901 — Re: The threading specs in the standard: a new catastrophe

jacob navia wrote:
...
> In general, I am not at all sure of WHY the C standard must decide this.
> Thread libraries are working OK, and POSIX pthreads is widely used.
>
> It would be better that the C standard would scrap all this and add
> a line:
>
> "The threads specifications follows the POSIX standard."
>
> Microsoft has implemented it under windows, and some companies
> have ported it to windows. Support from the C standard would
> be a good thing.

It's extremely unlikely to be that simple; the details of what it
means to follow only a part of the POSIX standard need to be
specified. I don't know anything specific about that part of the POSIX
standard, but I would guess that there's a good chance that it cross-
references other parts of the POSIX standard, either explicitly or
implicitly. If so, for each such cross-reference, the C committee
would have to decide whether to add that other section, too, or to add
words indicating how the meaning of that cross-reference should be
modified in the context of the new C standard. But let's assume all
such issues can be dealt with.

The result of such a change to the C standard would be that if there
is any code which relies only upon the current C standard, and that
portion of the POSIX standard, an implementation of C conforming to
the new C standard will be required to translate that code so that it
works in accordance with POSIX specifications, even if that
implementation is running on a Windows platform.

Now, William Ahern cross-posted a message to every group that this
message is posted to, except comp.std.c, in the thread with the
subject "POSIX threads hard to implement in Windows". In it, he
indicated that one of the biggest ways in which the Windows version of
pthreads differs from true POSIX pthreads is that Windows mutexes
cannot be statically initialized. Therefore, implementers of next
version of C on a Windows platform face a challenge: how to make
statically initialized mutexes work as they are required to by POSIX
(and therefore, also by the new version of C), even though they are
not permitted by the Windows version of pthreads.
I'm not very knowledgeable about this area myself, so it's entirely
possible that I've garbled William Ahern's meaning. Any corrections
that might be needed in order for that paragraph to make sense would
be greatly appreciated.

Since you yourself are a C implementer for Windows platforms, would
you care to describe an implementation strategy for dealing with this
challenge?

[toc] | [next] | [standalone]

#902

On Jul 7, 3:25 pm, jameskuyper <jameskuy...@gmail.com> wrote:
> jacob navia wrote:
>
> ...
>
> > In general, I am not at all sure of WHY the C standard must decide this.
> > Thread libraries are working OK, and POSIX pthreads is widely used.
>
> > It would be better that the C standard would scrap all this and add
> > a line:
>
> > "The threads specifications follows the POSIX standard."
>
> > Microsoft has implemented it under windows, and some companies
> > have ported it to windows. Support from the C standard would
> > be a good thing.
>
> It's extremely unlikely to be that simple; the details of what it
> means to follow only a part of the POSIX standard need to be
> specified. I don't know anything specific about that part of the POSIX
> standard, but I would guess that there's a good chance that it cross-
> references other parts of the POSIX standard, either explicitly or
> implicitly. If so, for each such cross-reference, the C committee
> would have to decide whether to add that other section, too, or to add
> words indicating how the meaning of that cross-reference should be
> modified in the context of the new C standard. But let's assume all
> such issues can be dealt with.
>
> The result of such a change to the C standard would be that if there
> is any code which relies only upon the current C standard, and that
> portion of the POSIX standard, an implementation of C conforming to
> the new C standard will be required to translate that code so that it
> works in accordance with POSIX specifications, even if that
> implementation is running on a Windows platform.
>
> Now, William Ahern cross-posted a message to every group that this
> message is posted to, except comp.std.c, in the thread with the
> subject "POSIX threads hard to implement in Windows". In it, he
> indicated that one of the biggest ways in which the Windows version of
> pthreads differs from true POSIX pthreads is that Windows mutexes
> cannot be statically initialized. Therefore, implementers of next
> version of C on a Windows platform face a challenge: how to make
> statically initialized mutexes work as they are required to by POSIX
> (and therefore, also by the new version of C), even though they are
> not permitted by the Windows version of pthreads.
> I'm not very knowledgeable about this area myself, so it's entirely
> possible that I've garbled William Ahern's meaning. Any corrections
> that might be needed in order for that paragraph to make sense would
> be greatly appreciated.
>
> Since you yourself are a C implementer for Windows platforms, would
> you care to describe an implementation strategy for dealing with this
> challenge?

The simplest mapping of the posix mutex type to windows is the
CRITICAL_SECTION data type.  The only difference between the two is
that a posix mutex may have attributes that allow it to be used to
synchronize between processes via a shared memory segment.  Since
multiple processes and shared memory go beyond the C standard, it
shouldn't need to worry about them.  Those concepts are platform
specific, after all.

Assuming you use a CS as a mutex, then the only nontrivial thing to
have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
Microsoft windows allow static initialization of these via the
definition:
#define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}

However, this isn't the end of the story.  One can do better by using
the low-level thread synchronization primitives that Microsoft uses to
implement locks and condition variables.  Using "keyed events" it is
possible to outperform the standard locking routines Microsoft
provides...

Steven

[toc] | [prev] | [next] | [standalone]

#907

On 07/07/2011 07:12 PM, sfuerst wrote:
> On Jul 7, 3:25�pm, jameskuyper <jameskuy...@gmail.com> wrote:
>> jacob navia wrote:
...
>>> It would be better that the C standard would scrap all this and add
>>> a line:
>>
>>> "The threads specifications follows the POSIX standard."
...
>> It's extremely unlikely to be that simple; the details of what it
>> means to follow only a part of the POSIX standard need to be
>> specified. I don't know anything specific about that part of the POSIX
>> standard, but I would guess that there's a good chance that it cross-
>> references other parts of the POSIX standard, either explicitly or
>> implicitly. If so, for each such cross-reference, the C committee
>> would have to decide whether to add that other section, too, or to add
>> words indicating how the meaning of that cross-reference should be
>> modified in the context of the new C standard. But let's assume all
>> such issues can be dealt with.
...
>> Now, William Ahern cross-posted a message to every group that this
>> message is posted to, except comp.std.c, in the thread with the
>> subject "POSIX threads hard to implement in Windows". In it, he
>> indicated that one of the biggest ways in which the Windows version of
>> pthreads differs from true POSIX pthreads is that Windows mutexes
>> cannot be statically initialized. Therefore, implementers of next
>> version of C on a Windows platform face a challenge: how to make
>> statically initialized mutexes work as they are required to by POSIX
>> (and therefore, also by the new version of C), even though they are
>> not permitted by the Windows version of pthreads.
>> I'm not very knowledgeable about this area myself, so it's entirely
>> possible that I've garbled William Ahern's meaning. Any corrections
>> that might be needed in order for that paragraph to make sense would
>> be greatly appreciated.
>>
>> Since you yourself are a C implementer for Windows platforms, would
>> you care to describe an implementation strategy for dealing with this
>> challenge?
> 
> The simplest mapping of the posix mutex type to windows is the
> CRITICAL_SECTION data type.  The only difference between the two is
> that a posix mutex may have attributes that allow it to be used to
> synchronize between processes via a shared memory segment.

That's a prime example of the cross-referencing problem I was referring
to: the committee would have to decide either to add a specification for
processes and shared memory, or to add wording beyond what jacob gives
above, modifying whatever it is that the POSIX standard says about such
things within the part that describes pthreads.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#916

"sfuerst" <svfuerst@gmail.com> wrote in message 
news:d8d63934-ea1d-4135-a5f2-1fd7b834042a@v12g2000vby.googlegroups.com...

[...]

> Assuming you use a CS as a mutex, then the only nontrivial thing to
> have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
> Microsoft windows allow static initialization of these via the
> definition:
> #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}

Can you point me to some documentation please?

Thanks.

[...] 

[toc] | [prev] | [next] | [standalone]

#917

On Jul 8, 12:47 pm, "Chris M. Thomasson" <cris...@charter.net> wrote:
> "sfuerst" <svfue...@gmail.com> wrote in message
>
> news:d8d63934-ea1d-4135-a5f2-1fd7b834042a@v12g2000vby.googlegroups.com...
>
> [...]
>
> > Assuming you use a CS as a mutex, then the only nontrivial thing to
> > have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
> > Microsoft windows allow static initialization of these via the
> > definition:
> > #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}
>
> Can you point me to some documentation please?
>
> Thanks.
>
> [...]

The CRITICAL_SECTION structure is defined in Winnt.h

Description of what the fields do is described here:
http://msdn.microsoft.com/en-us/magazine/cc164040.aspx
Basically, the above initializes things in the unlocked state, with an
invalid DebugInfo field.  This corresponds to the effects of
InitializeCriticalSection() when it cannot allocate memory.

Older versions of Microsoft Windows raise exceptions instead of using
the "invalid field" trick, so the above will not work for them.

Steven

[toc] | [prev] | [next] | [standalone]

#918

"sfuerst" <svfuerst@gmail.com> wrote in message 
news:b7a31b8c-bbfb-4b9e-b53c-4be3e94944cc@q15g2000yqk.googlegroups.com...

[...]

> Description of what the fields do is described here:
> http://msdn.microsoft.com/en-us/magazine/cc164040.aspx
> Basically, the above initializes things in the unlocked state, with an
> invalid DebugInfo field.  This corresponds to the effects of
> InitializeCriticalSection() when it cannot allocate memory.

> Older versions of Microsoft Windows raise exceptions instead of using
> the "invalid field" trick, so the above will not work for them.

Thank you. 

[toc] | [prev] | [next] | [standalone]

#923

sfuerst wrote:
> On Jul 8, 12:47 pm, "Chris M. Thomasson"<cris...@charter.net>  wrote:
>> "sfuerst"<svfue...@gmail.com>  wrote in message
>> news:d8d63934-ea1d-4135-a5f2-1fd7b834042a@v12g2000vby.googlegroups.com...
>> [...]
>>
>>> Assuming you use a CS as a mutex, then the only nontrivial thing to
>>> have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
>>> Microsoft windows allow static initialization of these via the
>>> definition:
>>> #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}
>>
>> Can you point me to some documentation please?
>
> The CRITICAL_SECTION structure is defined in Winnt.h
>
> Description of what the fields do is described here:
> http://msdn.microsoft.com/en-us/magazine/cc164040.aspx

Note, however, that the article is not an official Microsoft 
documentation, and indeed there's an Editor's Note at the top, which 
says one should not use such tricks in production code.
-- 
Marcin Grzegorczyk

[toc] | [prev] | [next] | [standalone]

#924

On Jul 9, 2:55 pm, Marcin Grzegorczyk <mgrze...@poczta.onet.pl> wrote:
> sfuerst wrote:
> > On Jul 8, 12:47 pm, "Chris M. Thomasson"<cris...@charter.net>  wrote:
> >> "sfuerst"<svfue...@gmail.com>  wrote in message
> >>news:d8d63934-ea1d-4135-a5f2-1fd7b834042a@v12g2000vby.googlegroups.com...
> >> [...]
>
> >>> Assuming you use a CS as a mutex, then the only nontrivial thing to
> >>> have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
> >>> Microsoft windows allow static initialization of these via the
> >>> definition:
> >>> #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}
>
> >> Can you point me to some documentation please?
>
> > The CRITICAL_SECTION structure is defined in Winnt.h
>
> > Description of what the fields do is described here:
> >http://msdn.microsoft.com/en-us/magazine/cc164040.aspx
>
> Note, however, that the article is not an official Microsoft
> documentation, and indeed there's an Editor's Note at the top, which
> says one should not use such tricks in production code.
> --
> Marcin Grzegorczyk

Which doesn't prevent Microsoft from using the technique in its own C
library one little bit. ;-)

Steven

[toc] | [prev] | [next] | [standalone]

#903

Mr Kuyper

If simply supporting pthreads is not so simple as I described (and
I fear you are right) why don't we leave that part out?

Why this rush to standardize another, competing standard in a highly
complex subject matter where most committee members aren't experts?

Can't we postpone this whole subject for a later edition? Why must
the committee do something in this direction?

Looking at the situation now and the errors that are discovered when we
look deeper into this, makes obvious that this whole business is a
VBI: a Very Bad Idea (tm).

Without trying to denigrate anyone it is obvious that most committee
members aren't experts in this thread stuff, as many people, there is
*nothing wrong* with that. They CAN'T KNOW EVERYTHING.

Both windows threads and POSIX pthreads are the work of specialists
of the field, and they are standards pushed by a company that has
enormous resources or by a community of users with thousands of
developers that have tested and explored the pthread design since YEARS
and YEARS.

To believe that the C standards committee with so few resources at
hand and with no significant user base at the start will succeed
is beyond what I can sanely conceive. This will take a lot of
time and an enormous effort from the committee members for dubious
results AT BEST.

Isn't a revamping of the standard library (that hasn't been really
updated since the seventies) more important for the C language?

Personally I just do not understand why this comes up. True, C++
has started a similar approach but they have a larger user community
and probably more industry support. And even in their case, any
new standard that would present the same glaring defficiencies
as the proposal of the draft we are discussing would be largely
ignored by a community where care of details is VERY important.

Designing multi-threaded programs is notoriously difficult and
people will be VERY reluctant to change the base support they
are working with since years. Specially if it is fundamentally
flawed. If you do not give the implementors the possibilty of
using ALL (or the most crucial) features of the underlying
OS this C API will never take off.

Please consider this viewpoint

Yours sincerely

jacob
-----------------------------------------------------
P.S. Concerning your question about static initialization,
ANY static initialization can be dynamically simulated by
code that runs before main() starts. Specifically

int myInt = 42;

can be simulated by

_cStartup() // this is the entry point
// ...
myInt = 42;
// ...
return main(argc,argv);

For the program, it is AS IF that integer was statically initialized.

[toc] | [prev] | [next] | [standalone]

#904 — some sane words, for sure

I'm pretty new to this thread, and I haven't followed what's been
written very closely even since I've noticed it, but this message
contains some very sane words and words of truth.

I agree wholeheartedly with the part I quote below.  If anyone reading
this does have contact with any committee members, I really hope these
issues can be raised with the committee.


jacob navia <jacob@spamsink.net> writes:
>
> If simply supporting pthreads is not so simple as I described (and
> I fear you are right) why don't we leave that part out?
>
> Why this rush to standardize another, competing standard in a highly
> complex subject matter where most committee members aren't experts?
>
> Can't we postpone this whole subject for a later edition? Why must
> the committee do something in this direction?
>
> Looking at the situation now and the errors that are discovered when we
> look deeper into this, makes obvious that this whole business is a
> VBI: a Very Bad Idea (tm).
>
> Without trying to denigrate anyone it is obvious that most committee
> members aren't experts in this thread stuff, as many people, there is
> *nothing wrong* with that. They CAN'T KNOW EVERYTHING.
>
> Both windows threads and POSIX pthreads are the work of specialists
> of the field, and they are standards pushed by a company that has
> enormous resources or by a community of users with thousands of
> developers that have tested and explored the pthread design since YEARS
> and YEARS.
>
> To believe that the C standards committee with so few resources at
> hand and with no significant user base at the start will succeed
> is beyond what I can sanely conceive. This will take a lot of
> time and an enormous effort from the committee members for dubious
> results AT BEST.

[[....]]

> Designing multi-threaded programs is notoriously difficult and
> people will be VERY reluctant to change the base support they
> are working with since years. Specially if it is fundamentally
> flawed. If you do not give the implementors the possibilty of
> using ALL (or the most crucial) features of the underlying
> OS this C API will never take off.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

[toc] | [prev] | [next] | [standalone]

#914

jacob navia wrote:
> Mr Kuyper
>
> If simply supporting pthreads is not so simple as I described (and
> I fear you are right) why don't we leave that part out?
>
> Why this rush to standardize another, competing standard in a highly
> complex subject matter where most committee members aren't experts?
>
> Can't we postpone this whole subject for a later edition? Why must
> the committee do something in this direction?

Because a properly written proposal has been placed before the
committee through the proper channels. At the very least, they had to
pay enough attention to the proposal to decide whether or not to
dismiss it immediately. The fact that they've actually done a lot more
than that implies that they have more appreciation for the value of
this proposal, and more confidence in their own competence to deal
with it, than you do. Those are judgment calls, and only time will
tell whether your judgment or theirs is more accurate (though you
understandably have a strong opinion on that issue already).

...
> Isn't a revamping of the standard library (that hasn't been really
> updated since the seventies) more important for the C language?

This is revamping the standard library; the new threading routines
will be a part of that library.

...
> P.S. Concerning your question about static initialization,
> ANY static initialization can be dynamically simulated by
> code that runs before main() starts. Specifically
>
> int myInt = 42;
>
> can be simulated by
>
> _cStartup() // this is the entry point
> // ...
> myInt = 42;
> // ...
> return main(argc,argv);
>
> For the program, it is AS IF that integer was statically initialized.

I know that; what I don't know, since I've never used it, is the way
in which the Windows version of pthreads prohibits statically
initialized mutexes. Do you know how that prohibition is enforced? Can
you confirm that the approach described above bypasses that
enforcement? Offhand, I can't think of any way of enforcing it that
could be bypassed by that mechanism, but that could just be a failure
of my imagination.
By the way, have you figured out how to make POSIX threads usable in
native Windows code? Larry Jones says that that Windows pthreads are
only supported for programs working within the limitations of their
POSIX subsystem.

[toc] | [prev] | [next] | [standalone]

#915

> I know that; what I don't know, since I've never used it, is the way
> in which the Windows version of pthreads prohibits statically
> initialized mutexes. Do you know how that prohibition is enforced? Can
> you confirm that the approach described above bypasses that
> enforcement? Offhand, I can't think of any way of enforcing it that
> could be bypassed by that mechanism, but that could just be a failure
> of my imagination.
> By the way, have you figured out how to make POSIX threads usable in
> native Windows code? Larry Jones says that that Windows pthreads are
> only supported for programs working within the limitations of their
> POSIX subsystem.

This is incorrect.  There are multiple libraries implementing the
posix threading library for the Microsoft windows platform.  None of
them have difficulty supporting the fact that posix mutexes require
the possibility of static initialization.  A simple google search for
"pthread windows" will give examples of how to do it.

Steven

[toc] | [prev] | [next] | [standalone]

#920

On 07/08/2011 01:47 PM, sfuerst wrote:
...
> This is incorrect.  There are multiple libraries implementing the
> posix threading library for the Microsoft windows platform.  None of
> them have difficulty supporting the fact that posix mutexes require
> the possibility of static initialization.  A simple google search for
> "pthread windows" will give examples of how to do it.

On 2011-07-07, in c.l.c, c.p.t, and c.u.p, in a message with the subject
"POSIX threads hard to implement in Windows", William Ahern wrote:
...
> But anyone who has used POSIX threads and Windows' native API quickly learns
> that they're quite different approaches. The biggest difference that I'm
> aware of is that Windows' mutexes cannot be statically initialized.

Unless I'm misunderstanding something, which is quite possible, you and
he appear to be in disagreement on this point. If so, could the two of
you discuss this issue and resolve that disagreement?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#921

James Kuyper wrote:
> 
> On 07/08/2011 01:47 PM, sfuerst wrote:
> ...
> > This is incorrect.  There are multiple libraries implementing the
> > posix threading library for the Microsoft windows platform.  None of
> > them have difficulty supporting the fact that posix mutexes require
> > the possibility of static initialization.  A simple google search for
> > "pthread windows" will give examples of how to do it.
> 
> On 2011-07-07, in c.l.c, c.p.t, and c.u.p, in a message with the subject
> "POSIX threads hard to implement in Windows", William Ahern wrote:
> ...
> > But anyone who has used POSIX threads and Windows' native API quickly learns
> > that they're quite different approaches. The biggest difference that I'm
> > aware of is that Windows' mutexes cannot be statically initialized.
> 
> Unless I'm misunderstanding something, which is quite possible, you and
> he appear to be in disagreement on this point. If so, could the two of
> you discuss this issue and resolve that disagreement?

sfuerst is right, a la pthread statically initialized mutexes are no
problem under Windows native API, e.g.:

#define SWAP_BASED_MUTEX_FOR_WINDOWS_INITIALIZER { 0, 0 } 

class swap_based_mutex_for_windows { 

  /* ... */ 

  // -1: free, 0: locked, 1: contention 

  atomic<int>                m_lock_status;   
  atomic<auto_reset_event *> m_retry_event;  // Windows bin semaphore 

  /* ... */ 

  void lock() { 
    if (m_lock_status.swap(0, mem::acquire) >= 0) 
      slow_lock(); 
  }   

  void unlock() { 
    if (m_lock_status.swap(-1, mem::release) > 0) 
      m_retry_event.load(msync::none)->set(); 
  } 

  void slow_lock() { 
    auto_reset_event & retry_event = DCSI(); 
    while (m_lock_status.swap(1, mem::acquire) >= 0) 
      retry_event.wait(); 
  } 

  auto_reset_event & DCSI() { 
    auto_reset_event * retry_event; 
    if (!(retry_event = m_retry_event.load(mem::acquire)) { 
      named_windows_mutex_trick guard(this); 
      if (!(retry_event = m_retry_event.load(mem::non_competing))) { 
        retry_event = new auto_reset_event();
        m_retry_event.store(retry_event, mem::release); 
        m_lock_status.store(-1, msync::release); 
      } 
    } 
    return *retry_event; 
  } 
} 

The tricky part is to make slow_lock() not fail due to "new
auto_reset_event()" failure... but that is solvable as well using
fallback to a single preinitialized event count, effectively turning
binsema's set() into eventcount's broadcast().

regards,
alexander.

[toc] | [prev] | [next] | [standalone]

#922

Le 09/07/11 13:59, Alexander Terekhov a écrit :
[snip]

Thanks a lot for this information. It fills a crucial point we
were discussing.

[toc] | [prev] | [next] | [standalone]

#928

"Alexander Terekhov" <terekhov@web.de> wrote in message 
news:4E184289.9D95CABB@web.de...
[...]

>      named_windows_mutex_trick guard(this);

IIRC, that trick uses something like this to generate a name for the mutex:
_____________________________________________________
std::string
win_static_init_generate_name(
    void const* ptr
){
    DWORD pid = GetCurrentProcessId();
    DWORD_PTR oid = (DWORD_PTR)ptr;

    std::stringstream name_buf;
    name_buf << "SINIT_" << pid << "_" << oid;

    return name_buf.str();
}
_____________________________________________________

Right? 

[toc] | [prev] | [next] | [standalone]

#933

"Chris M. Thomasson" wrote:
> 
> "Alexander Terekhov" <terekhov@web.de> wrote in message
> news:4E184289.9D95CABB@web.de...
> [...]
> 
> >      named_windows_mutex_trick guard(this);
> 
> IIRC, that trick uses something like this to generate a name for the mutex:
> _____________________________________________________
> std::string
> win_static_init_generate_name(
>     void const* ptr
> ){
>     DWORD pid = GetCurrentProcessId();
>     DWORD_PTR oid = (DWORD_PTR)ptr;
> 
>     std::stringstream name_buf;
>     name_buf << "SINIT_" << pid << "_" << oid;
> 
>     return name_buf.str();
> }
> _____________________________________________________
> 
> Right?

Right.

http://lists.boost.org/Archives/boost/att-92840/once_mutex.hpp

std::string create_unique_name(void* p,const char* tag)
{
    std::ostringstream res;
    res<<"unique-"<<tag<<"-name-{C15730E2-145C-4c5e-B005-3BC753F42475}-"
       <<p<<"-"
       <<::GetCurrentProcessId();
    return res.str();
}

regards,
alexander.

[toc] | [prev] | [next] | [standalone]

#934

Alexander Terekhov <terekhov@web.de> writes:
> James Kuyper wrote:
> > 
> > On 07/08/2011 01:47 PM, sfuerst wrote:
> > ...
> > > This is incorrect.  There are multiple libraries implementing the
> > > posix threading library for the Microsoft windows platform.  None of
> > > them have difficulty supporting the fact that posix mutexes require
> > > the possibility of static initialization.  A simple google search for
> > > "pthread windows" will give examples of how to do it.
> > 
> > On 2011-07-07, in c.l.c, c.p.t, and c.u.p, in a message with the subject
> > "POSIX threads hard to implement in Windows", William Ahern wrote:
> > ...
> > > But anyone who has used POSIX threads and Windows' native API quickly learns
> > > that they're quite different approaches. The biggest difference that I'm
> > > aware of is that Windows' mutexes cannot be statically initialized.
> > 
> > Unless I'm misunderstanding something, which is quite possible, you and
> > he appear to be in disagreement on this point. If so, could the two of
> > you discuss this issue and resolve that disagreement?
> 
> sfuerst is right, a la pthread statically initialized mutexes are no
> problem under Windows native API, e.g.:
> 
> #define SWAP_BASED_MUTEX_FOR_WINDOWS_INITIALIZER { 0, 0 } 
> 
> class swap_based_mutex_for_windows { 

When discussing language features, what would be more useful is 
an example in the language in question, namely C.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web