[haiku-commits] Re: haiku: hrev51184 - headers/posix

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 1 Jun 2017 07:15:48 +0200

On 29.05.2017 16:55, PulkoMandy wrote:

You may be able to call create_sem() inside the array initializer?

{ 0, -1, create_sem(0, "pthread rwlock"), 1, 0, 0 }

However, this leaves the problem of initializing the WaiterList, as
the structure isn't public so we can't call its constructor from the
macro.

The list is represented as two pointers in the public structure (yes, ugly, but the alternative is using a C list structure). Simply initializing those to null would be fine.

Maybe it is possible to replace the whole implementation of pthread
r/w locks with something that doesn't need this much init, too.

Yes, the pthread rwlock implementation at least for process-private locks should be adjusted, so that the initializer cannot fail. For reference, I did the same for the mutex implementation in hrev36323 (among other things) in a binary compatible way. The idea is to repurpose one of the benaphore fields as a user mutex variable (the other field becomes unused). So this change should only affect LocalRWLock::Structure{Lock,Unlock}() and the initialization of the fields.

The implementation for process-shared rwlocks can remain as is. It isn't affected by PTHREAD_RWLOCK_INITIALIZER(), since it isn't the default lock type and therefore requires initialization via pthread_rwlock_init() anyway. Using a semaphore isn't particularly elegant, but a more efficient implementation would require additional kernel support.

CU, Ingo


Other related posts: